Free alternative to Skype?
Posted 30 Apr 2005 at 14:35 UTC by davidw
In the comunications arena, positive network externalities, or "network effects" are very important. The more people use something, the more valuable it is. The free software comunity is well positioned in standards based VOIP markets (or so it would seem to this observer from afar), but Skype seems to be taking off very quickly for the single user market, because it is so easy to install and use. Are there viable free alternatives?
I'm primarily interested in discussion of the alternatives out there, how well they work, on what platforms, and so on. I've seen a few things out there such as Kphone and IAXclient, but I don't know enough about the field to really say anything about any of them. Is there anything out there that can challenge Skype? Should we try, or perhaps just reverse engineer it and interoperate with it, accepting it as a de-facto standard?
that's all and that works
It would be nice if someone did do this. It's sad to see proprietary software as the best alternative for this.
Most of the hard pieces are available already; someone just needs to put them together, like Skype did. The reasons for its success are good crossplatform support and seamless routing through NAT. The first is just work, and the second is fairly well understood now. There's even a standard protocol for a client to discover and probe its NAT filter, if any.
And in the Speex project we have a free voice codec, both narrow and wide band. Skype apparently uses iLBC as a narrowband codec. I'm unclear on it's patent status; on the one hand the IETF blessed it, on the other, its authors claim general patent converage over their technologies.
Skype is known to use a Gnutella-like protocol (q.v. that spec such as it is). Thus well connected peers route for poorly connected ones, Unlike typical Gnutella implementations, there are hard-wired supernodes that prevent net splits and provide the commercial routing to the regular telephone network. Of course there is Free Software implementing this sort of network already, or one could go with a more traditional negotiated proxy.
In any case, Jean-Marc Valin, the speex codec author, has some ideas on how best to proceed if anyone's interested in taking this on.
Whether to reverse engineer or provide a competing implementation is always the question. I'd like to see both. From the point of view of a completely free implementation interoperability would probably be limited; which the narrowband iLBC codec is published, the other two (including Global IP Sound's wideband iSAC) are not. The other part is that Skype's business model of selling connections to the POTS network is an important piece for usefulness and usability. In an open implementation, this would be a service anyone could provide; we won't know if that's possible within the Skype framework until we understand it better.
Re: ophone, posted 2 May 2005 at 10:50 UTC by alfie »
You have searched for packages named ophone in all distributions, all sections, and all architectures.
Can't find that package.
ITYM ohphone. Though you have to first select which protocol you are longing for. ohphone and gnomemeeting (though it is mainly for video conferencing) are H.323, then there is kphone and linphone which support SIP.
It is hard to find a good application though. Those four have all their (major) drawbacks, and even for SIP there is now x-line in binary form available for Linux and not only OSX....
I'm owning a hardware phone myself, the shortcomes of the softphones are really limiting. I can recommend wholeheartly getting one of the SNOM phones. They are quite reliable, and the best is: the firmware is available under the conditions of the GPL. So you can fix it yourself and extend it to your likes. Yeah!
The first really usable VoIP software I used was Net2phone - Propietary throughout, medium quality, but worked fine. My mother even bought a Yapjack to let her forget she was really using a computer... Main problems? First of all, sound quality is flaky at best. Second, it is terminally non-free, and I don't want to run non-free software on my computer.
I have used kphone for over a year already, and am decently pleased with it. Contrary to what the name indicates, it is not tied to KDE, which is a big plus in my book - It just uses Qt. Small, works nicely. Sound quality is better than with Net2phone, but it is still far from perfect. It is a standard SIP client, has plenty of available codecs - you just have to hit a decent service provider. I am using Ibell, which is certainly less than spectacular and often has connectivity problems... But 25 dollars have lasted me almost the full year, calling at least twice a month to my mother in Sweden for ~20 minutes each time.
What amazed me in Skype since the first time I saw it is the sound quality. It has great echo cancellation (it is impossible to use kphone or Net2phone without headphones), and the voice quality (even over a 56k modem connection) is very good - Get broadband, and it just becomes great. But anyway, kphone is good enough for me.
IAX and iaxComm, posted 7 May 2005 at 04:44 UTC by ncm »
The biggest scam in VoIP is the "$15/mo" account. The good ones just take money on account and draw it down as you use it, with no minimum per month. So far I have yet to top $5 usage, at 1.3c/min out to PSTN (public switched tel network), 2c/min in via an 888 number.
IAX2 is the Asterisk protocol (often called just IAX, 'cause nobody uses IAX1 any more) that is simple, efficient, and works great behind firewalls. That is, it's a little better than SIP, and a lot better than H.323. All the very best services accept it. (That's one way to tell if they're any good.)
A package called iaxclient has a library, libiaxclient, and a bunch of iax soft phones, most interestingly IAXComm. It's not terribly mature, but it works. (E.g. I had to use iaxComm 1.0-rc1 because later versions fail, for me.) IAXComm uses libportaudio to operate OSS audio on Linux, whatever on Macosix and Win32. (The portaudio people are working on version 19 with support for ALSA and JACK, but it's not ready yet.) There's no Debian package yet, but you can build portaudio and iaxclient from sources on Debian Mentors. Word of warning: build the iaxclient package using portaudio-dev, not portaudio19-dev.
Free World Dialup finally got an IAX gateway, albeit well-hidden at iax2.fwdnet.net. (The FWD website is strange: be sure to find the "site map" button concealed in the lower left corner.) FWD is most interesting for their voicemail->email gateway and for their gateways to lots and lots of ITSPs. Having a gateway to/from FWD is another way to tell if a service is any good.
Things are still very far from mature. There is very little useful information available about how to set up Asterisk. aside from cookbooks that don't actually explain what anything you're typing really means -- much like the early days of Apache. If you do set up Asterisk, you can have it talk both IAX2 and SIP to the outside world and whichever to your hard- or soft-phone, so you're not stuck in one camp or the other.
skype is port-independent and deploys many techniques that are only possible with a distributed network that make it more robust - and attack-resistant.
"normal" voip relies on exclusive use of one port and one port only, and it also relies on your users having an understanding of NAT and Firewalls, because incoming calls are mapped to the concept of an incoming TCP or UDP connection.
these two things make it both easy for an ISP to chop off service at the knees, and it also makes it difficult for users to install.
VoIP is causing a destruction of the trust between ISPs as they fight for money in the telecoms arena: most ISPs _are_ telecoms and they can claim that they are perfectly within their rights to degrade service in order to prioritise their "paying" customers.
so skype is actually a much bigger deal than the original author of this article suspects.
the solution is, i believe, to write a distributed VPN framework, over which _any_ protocol may be run.
such VPN software should provide low-bandwidth, low-latency, and utilise some of the tricks that skype does - over which things like SIP and H323 can be made much more reliable.
the tricks employed by skype include MOVING connections between different intermediaries, making MULTIPLE connections via intermediaries and assessing which one is the best, then switching to it or simply using them both and throwing away duplicate packets, double-UDP NAT-busting techniques (documented as an RFC btw, can't remember which one), routing of incoming connections via existing outgoing TCP/UDP connections to intermediate peers in the distributed network, and a whole boat-load more that i can only guess at.
the key is the distributed network and the massive percentage of dickhead windows people who don't bother to set up firewalls properly: if it wasn't for these, there would be no intermediaries which could be utilised for more securely configured systems to initiate incoming connections.
in short, existing free software VoIP solutions provide an utterly pathetic framework compared to skype, for the usual "brain-dead" noddy user who just WantsItToWork(tm).
asterisk, posted 8 May 2005 at 17:48 UTC by lkcl »
asterisk's documentation is deliberately obscure and hostile in order to help increase the amount of money going into the developer's pocket.
it's also compiled by default to use a proprietary phone card for "timing".
i believe that several people - not least one of my colleagues - have modified and recompiled asterisk to remove this unnecessary proprietary dependency.
lkcl: the documentation isn't great, but it isn't entirely inpenetrable either. There's a Wiki which, as with all Wikis, contains information which is plentiful but variable in quality.
The timing stuff to which you refer is not required except for certain applications such as conferencing, and doesn't require a proprietary card. In the 2.4 kernel it can use a UHCI USB controller, and in 2.6 it doesn't need any special hardware at all.
There are GPL'd kernel modules which provide this timing functionality, as well as driving a bunch of Digium's phone hardware. It is suboptimal that these drivers are not yet merged into Linus' tree, and it's suboptimal that you need them just for timing purposes even if you don't have the hardware in question. People are looking at fixing the latter by using the new timer functionality which is available from recent kernel/glibc. If you claim to have patches which do this... please provide them.
UDP?, posted 13 May 2005 at 02:58 UTC by ncm »
Luke, can you tell us more about this "double-UDP NAT-busting technique"? As I understand it, it is very common for firewall administrators to reject all incoming UDP traffic except on ports for which the protocol is known to be robust against spoofing -- generally privileged ports.
IAX2 is supposed to use UDP, also, although the docs don't say how.
How do you know about how Skype works? It's more poorly documented (at least for us) than asterisk, being entirely proprietary. Of greater concern to me than ISP games is that there is no attempt at security or prevention of spamming on any of the VoIP protocols.
To compete with Skype, you pretty much have to develop something that grandma can use, or, in my case, my parents that live on the other side of the planet. That's my practical interest in all this. You need cross platform and extreme ease of use to generate a big enough network to take on the other competitors - the bigger the network, the more valuable it is.
Apples and oranges, posted 15 May 2005 at 23:57 UTC by slamb »
Asterisk and Skype don't solve the same problem. Skype's software is a soft phone; Asterisk is a PBX. The Skype people do the functions of Asterisk (like voicemail and PSTN gateways) for you. You can find other places that do those same things for standardized VOIP, so you don't need to run Asterisk yourself.
Asterisk's intended audience (hobbyists, ISPs, telecoms, and corporate IT departments) should have no problem with the documentation. I've been playing with it, and I found most of what I needed in the handbook and wiki. It's not perfect, but it's not bad, and it's improving.
Here are a couple real reasons Skype is dominant over standardized VOIP systems:
The audio quality of standardized VOIP is lacking. Mainly because Skype uses 16 kHz audio, while PSTN and VOIP use 8 kHz audio, but also because of other problems (latency, packet loss) that Skype has done a good job of minimizing. Read some papers (1) (2) (3) on the subject and you'll see what I mean. Or do an experiement yourself - record your voice, downsample to 8 kHz and 16 kHz, and see if you can spot the difference. ("Be sure to say 'f' and 's' in your recording.) I did, and it was a huge difference. Unfortunately, the 8 kHz problem isn't trivial to fix - Asterisk has lots of assumptions about 8 kHz audio, the protocols have these same assumptions, and so do all the available softphones.
The available softphones suck UI-wise. This is the software that Aunt Tillie should be able to use, and it's hopeless with the existing packages. This is probably the biggest reason Skype is so dominant. xten makes the best ones I could find, and they make some classic UI blunders. (Like emulating a physical device instead of using computer UI's advantages.) It's also not open source. I encountered a bug that made the already-bad 8 kHz audio all but unintelligible. Good luck getting that fixed...
I haven't tried the IP hardphones; they may be sufficiently easy to set up. But they all have the 8 kHz audio problem also, and the softphones are what people are going to try first. They're skeptical that this Internet thing can produce better phone calls, so they'll want to try it out before committing to spending money on a physical device.
the technique goes something like this (and it's described fully in detail in that draft rfc i can't remember the name of):
A initiates a UDP connection to B, from port A-in to port B-out, thereby making B create a UDP NAT "hole".
B simultaneously creates a UDP connection to A, from port B-in to port A-out, thereby making B create a UDP NAT "hole".
both A and B now talk on port A-in to B-in, and the NAT "holes" each way allow that to happen, and for a NEW NAT "hole" to be created.
i'm not sure if the above description is correct, it's very tricky, it does work, and it's blown out the water by having firewall rules blocking UDP traffic.
how skype works, posted 5 Jun 2005 at 11:43 UTC by lkcl »
their earlier versions of their web site had (still have?) some documentation on it, describing how some of their stuff works.
also, the service level agreement says "you must allow people to utilise some of your network and CPU bandwidth".
also, the fact that skype _does_ work even if you only have outgoing TCP allowed in your firewall TELLS you that they MUST be using back-routing of incoming phone calls.
also, if you look at the XML config files, you will see that the file contains 100 "random" IP addresses.
also, if you watch (strace) skype, you will see that it does a traceroute to all of those IP addresses.
there are many things going on in skype, that can be deduced from observation of the facts.
how do i know? i don't.
flights of fancy, posted 5 Jun 2005 at 11:52 UTC by lkcl »
i love being told i am off on a flight of fancy. not everyone in the world is a hard-core software developer, dwmw2.
for a distributed net VoIP software system to work it must:
1) be xxxxing easy to use
2) be xxxxing easy to set up (i.e. require NO setup)
3) take off like wildfire
4) be available for windows
asterisk isn't available for windows, and it's not easy to set up, let alone use.
i don't believe any of the free software VoIP are available for windows, and they're not easy to use, and they're ALL difficult to set up (require NAT f/w rules)
skype on the other hand fits all of the requirements.
oh - the only thing that's a pisser about skype is that the CODEC they've chosen is VERY cpu intensive. if you swap windows to your browser on windows and let it get ANY cpu time it could, in early versions, cause skype to disconnect.
the jitterbuffer that skype has added in since then now helps mitigate against some of these earlier disasters, but it's still not "good".
no, GSM is _not_ a good CODEC to use instead.
iaxclient, posted 5 Jun 2005 at 12:00 UTC by lkcl »
iaxclient, when ported recently to a 90Mhz ARM720T, proved disastrous. the "canary" thread died before it was started, and the increasing of the audio thread's priority to "max" caused the entire device to lock up.
what i had to do was track down qtiax, which had had enough bits of iaxclient cut out of it to make it useable (and then i had to add back _in_ the use of speex because the darn idiot who created qtiax went and removed all codecs but GSM).
all of these things are "useful" - and make us developers "happy" because we _can_ use them.
that leaves everyone else - the dummies, shall we say - out in the cold.
a firewall/NAT-busting VPN would make it possible for us to still provide VoIP in the way that WE want to do it - whilst at the same time providing a generic and configureable solution that will benefit _everybody_.
asterisk and 8Khz, posted 5 Jun 2005 at 20:55 UTC by lkcl »
yep - pisser, isn't it?
i had the misfortune recently to have to work at 6Khz instead of 8, due to not having enough CPU power to run Speex at 8Khz on a 90Mhz ARM 720T - and that was _after_ the company had commissioned jean-marc valin to write some portions of speex in assembler.
what i had to do was obtain libsamplerate and perform a sample-rate conversion, and make asterisk _think_ it was receiving and sending 8Khz audio.
this "mostly" works well, although i don't have enough experience with asterisk to have got the "number of samples per frame" perfectly right, yet.
but yes - basically, without a major overhaul in asterisk, you're hosed if you want anything other than 8kHz.
if you DO want to do non-8Khz, make DAMN sure you pick a decent samplerate conversion library.
Dummies?, posted 20 Jul 2005 at 01:52 UTC by ncm »
I prefer "know-nothing bozos", in homage (IIRC) to Douglas Adams.
So it took me a while to notice, but FWD is no longer free as of last October/August of 2008. Read all the details here:
Way to go, build a community, then rip the free nature out from under the community. I even placed toll free calls specifically with them knowing that in some small way it was supporting them.
If anyone runs across alternatives that are
d) VoIP (sip or iax)
please do mention it here.