[Fsuk-manchester] Software Freedom Day: Hunt for Skype alternatives

[Daniel Pocock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 04/10/12 11:52, Myriam Schweingruber wrote:
> On Tue, Oct 2, 2012 at 7:34 PM, MJ Ray <mjr at phonecoop.coop> wrote:
>> Dan MacDonald <allcoms at gmail.com>
>>> [...] and if you're a gmail user then its nice not having to
>>> install and configure an extra client- it generally 'just
>>> works' TM, R etc
>> 
>> Except when it doesn't, then you're stuffed.
>> 
>>> So, there are no working XMPP/Jingle clients for neither JACK
>>> nor KDE/Qt? :/
>> 
>> Surely some of them on 
>> https://fsfe.org/news/2012/news-20120920-01.en.html#id-table
>> work under KDE?  Kopete seems suspicious to me.  Actually, the
>> table could do with a "protocol" column, as some (Jitsi, for
>> example) can do more than one.
> 
> Because Kopete is pretty much outdated and unmaintained, nowadays
> one should use kde-telepathy for that, works quite fine here for
> XMPP.
> 


I'm not sure if I can reply to all the lists on CC, but would it be
possible to set up a dedicated list for this initiative, or could I
offer to host a list for this purpose at OpenTelecoms.org ?

http://lists.opentelecoms.org

A lot of the material at http://www.opentelecoms.org (especially under
the Federated VoIP heading) could really help this initiative, the key
points are:
- - using TLS as default for both SIP and Jabber (SIP over UDP is
usually the default, but has too many NAT and MTU hassles these days)
- - using ICE and TURN for NAT traversal (but beware of gotchas, e.g.
Jitsi currently only supports ICE with Jabber and not SIP)
- - the codec suggestions (clients must implement as many as possible)

I've also posted some comments recently on the FreedomBox list:
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-September/004576.html
and there was some feedback and discussion,  I'm copying my comments
here as they are directly related to this discussion:

- ---------
I would certainly like to be involved in that and contribute what
resources I can to support it

I believe the testing needs to be a little bit more scientific and not
just take the `black box' approach, assessing each product on the
following perhaps:

- - supported codecs (e.g. patent free, suitable for mobile, ...)  - and
which products support the codecs that other products use (matrix)?

- - how easy is it for user to get the `right' codec for their call?  Is
it automatic (Skype has dynamic selection of codec based on bandwidth,
many free software products don't do this)

- - which solutions support NAT traversal?  Is every permutation of NAT
and firewall environment tested?  ICE/STUN/TURN is good for this, but
client software support is not always 100% (e.g. Jitsi supports ICE with
Jabber, but not with SIP.  Lumicall supports ICE, but there are some
shortcomings, just look for the FIXMEs in the code to find out what they
are)

- - how should users register for a truly `Free' VoIP network?  Virtually
all existing clients require users to both choose a provider and set up
a SIP account, and it is always more difficult than setting up Skype

- - if there are many independent providers and small businesses running
their own private VoIP, and the client software does somehow allow the
users to connect to their chosen provider, they could be left in a
little island (that is often the case today).  How can they easily
interconnect to users with different providers?  This is one of the
questions I've been trying to solve with my `Federated VoIP' pages:
http://www.opentelecoms.org/federated-voip

- - what solutions are suitable for both corporate and private use?  A
lasting solution must be universal.  Microsoft now has both the
corporate domain (Lync) and consumer (Skype) and will most likely try to
join them together more closely, and then do their usual trick of
bastardizing the protocol and locking out alternative solutions.
Given the existing widespread use of Skype, this is scary stuff.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQbWNAAAoJEOm1uwJp1aqDZt4QAJOT0y7iE4VXgKDHh4QAiuzL
Kn7be1novDiSKgUZNqiYOTHXnCNGtBrFLcxEdPlh1KtHcp2xXPRwloGDGKkZSE9M
cv1CSW1Wm7hx2EzBe8hceGRw9LpkKqA8nNhqjlvFhOwLdM4J6yIbK90jQ2xHLmc0
R5U6x05UCuR6TH6p6pKCMiDqEHWe6dlX1rgv6YQ6yK7Y+c1xpfH2/9B+JpoNnunH
WtU8mFzAyKH1yDzYoujdeVXErfwgeMEnId7c55I8bc9LZCQw/qhZQ6b0iZd29v4w
l96HswlQ5M1EkUGMeSQU6wlcBjqV31hSPfaAipL+jznbV2ONLjAhgBRYTj1Wn63R
Ho31WQy4Uxr1OKziXkAsCvEreXVs6ah7j/k2yh9KT6C+bbd8BBz6b7Glmd+IWaX1
HYAYS1vyr9BkoC9h88I+nmj6wHvWsa37k3KFg88iNAlgCJYVmL6vu9vjuir0cTf0
XWn7k8Ct2zj/ecuYdPmuxeoC/jOUYGuumGTuWLh5MwTCgONQuOm4iRWQ0aoTjafl
ZuOrJ7r9RHLEayTMttiP95h0fLdnlySrs8WNLbyzV0XHVz46ZRJu/BXsm/h0n5jp
cQVEhVze7GqyH5ACCPKsXRQcN8esY4LuTHPsBSbBE+lGnJAFwNmnvXeHdmmLkaoJ
AxHiwSjofi353YIZsUDG
=U+st
-----END PGP SIGNATURE-----