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

Daniel Pocock daniel at pocock.com.au
Thu Oct 4 10:21:52 UTC 2012

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

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 ?


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:
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

- - 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:

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

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


More information about the Discussion mailing list