VoIP call transfer?

[adrian cockcroft]

On 4/2/07, Paul McMillan <Paul at semicubic.com> wrote:
> Adrian, thanks for an insider's viewpoint.

Likewise, thanks for this detailed response.

>
> What you describe (a Linux/ARM gateway binary) would be an acceptable
> solution for many people, since it wouldn't overly burden the device with a
> full-blown Skype client, and would provide the connectivity to integrate
> Skype contacts alongside sip and other voip protocol contacts. I would
> probably use it myself, considering how many people I know who use Skype...

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?

>
> The other thing that worries me about Skype and this device is the license
> for the Skype api... It's not an open source license, and it really departs
> quite heavily from such ideals, to the point that many OS developers would
> probably refuse to work on a project involving it because of the constraints
> and requirements it places on their heads.

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.

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.

> For anyone who hasn't looked at it, it can be found here:
> http://www.skype.com/company/legal/terms/api.html

Yes its pretty one-sided, like many corporate legal docs.

> The areas I feel are objectionable:
> 2.(b) Doesn't clearly define hardware device. Does an application installed
> on the NEO qualify? I think it's rational to argue that no, OpenMoko is a
> platform, users can install whatever they want, but an argument in court
> would point to other "hardware devices" like handsets and say that the NEO
> was no different, and thus subject to the additional requirements including
> that all developers be part of Skype's Hardare Partner Scheme.

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.

> 3.6 Potentially limits our ability to make the service useful... If we can't
> cache the Skype password (and I'm assuming the api won't let us do that
> either, I could be wrong), then we can't provide good functionality to users
> who are moving in and out of internet coverage. This might be different in
> the terms for an embedded oriented solution. Ideally, the user will never
> have to interact with a skype-branded interface, since our goal here is
> total integration.

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'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.

>
> 6. Places a great burden on developers. You become technically liable the
> moment a new version is released. Open source developers are very wary of
> even the most technical legal liability, since groups trying to kill open
> source projects will often seize upon said liability and base entire court
> cases around it. This also makes no provision for developer testing to make
> certain the new version doesn't break their software before deploying it.

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.

The underlying Skype API is very simple for example

https://developer.skype.com/Docs/ApiDoc/CALL

To call someone you send the string "CALL someone" to the connector,
thats it. To get a contact list of SkypeIDs you send "SEARCH FRIENDS".
Not exactly rocket science. In Java you have the objects and methods
to do more complex things including app2app messaging between plugins
more easily.

Adrian