Linux-Friendly Alternatives To Skype 236
jfruhlinger writes "When Microsoft bought Skype, Linux and Mac users were assured that their platforms wouldn't be neglected — but you can understand why they might be a bit suspicious. Steven Vaughan-Nichols has compiled a list of five Linux-friendly alternatives — do you know of any others?"
Sky .NET (Score:3, Interesting)
Re:Sky .NET (Score:4, Interesting)
What does "normal people" mean here? I'm middle-aged and married with teenage kids. We own our house, cars, etc.
I think that refers to people who *don't* read slashdot. :D
Bandwidth Used To Matter, But Not Much Today (Score:4, Interesting)
Back when I started dealing with VOIP, bandwidth mattered a lot, because a typical home user had a modem, and a typical business office had a T1 voice line or less for a bunch of people and would like to be able to get both voice and data onto the same line to save money, or they were trying to make international connections to countries with extremely overpriced monopoly telcos and wanted to save a lot of money So a 64kbps codec, which burned 80kbps or more after IP overhead, was way too big - an 8kbps codec would fit onto a 14.4 modem, but didn't quite fit into 9600 async. When I first got DSL at home, it was 384kbps symmetric, and when I first got ADSL, it was 1.5/128, which was actually worse for VOIP because you had to be careful to prioritize the VOIP on your upstream.
On the other hand, PCs didn't have a lot of horsepower back then, so if you wanted to run on a 386/33, you couldn't use some low-bit-rate codec that burned 40 bogomips. The crossover hit somewhere around the 486 timeframe, where your processor was fast enough to run a codec that would fit on your modem and sound better than a Speak&Spell. By the time Pentiums came out, 28.8kbps modems were also showing up, and codecs were getting better - there are a number of 16kbps codecs requiring under 30MIPS, and the cruder ones could run fine on an Arduino, but with Pentium horsepower you can easily run codecs at 8kbps or less.
If you're trying to run VOIP on a cellphone to save money, you've probably got a 3G smartphone, so you've got 400+ MHz of CPU to play with, and latency is more of a problem than bandwidth (though it's a lot better than on 2.5G networks.)
The real problems that Skype solved were
The latter problem is the difficult one.
Re:Skype v SIP (Score:5, Interesting)
Slashdot could really use FAQs. I swear I type this response every year ;-)
The problem with NAT traversal is that SIP and RTP require you to use a large number of ports. If both sides are behind NAT, STUN is used to determine the network facing port number and SIP is used to communicate that port number. But the problem is that if you receive a packet before you send a packet, the firewall will send an ICMP packet back. This is not a problem in itself, but many, many firewalls (including Linux based ones at one time) *bind the port* for a while after sending the the ICMP packet. When you get around to sending the packet, the firewall reassigns the network facing port number. Voila; one way audio! No amount of STUN (or ICE) will help you. And, as I said, a *very* large number of routers exist with this problem.
This problem has actually been know for decades (although I've been told it is against the spec). The way you are *supposed* to solve the problem is to write your protocol so that incoming packets come in on only one port. You then port forward that port to the correct place. This is what is meant when we say that the SIP protocol is broken (well, it's also really, really poorly designed in a number of other areas, but those are mostly fixable). Why don't we design a protocol that isn't broken? Because there is no point. Nobody's grandmother knows how to port forward on their router anyway, so its a moot point.
In the meantime, we are faced with one way audio problems in a large number of cases where both sides are behind NAT, even when we use STUN. The way we *actually* fix the problem is by putting a media proxy (session border controller) in the middle. This is a device that is not behind NAT. It acts as a proxy for the call. Both sides connect to the proxy and the proxy forwards the packets. It waits until both sides have sent packets before it forwards them. This fixes the problem. But the downside is that the proxy has to carry the traffic for the whole call.
Skype also has this problem. My understanding is that Skype is using a modified version of SIP underneath anyway. The way Skype solves this problem is by identifying clients that aren't behind NAT. Those clients are used to proxy the media for other clients that are behind NAT. In other words, if you use Skype and you aren't behind NAT, there's a good chance you will be carrying traffic for those that are behind NAT. Free software authors *could* implement this functionality, but those that actually understand the problem (a small number of people) generally think this approach is evil. The general approach has been to rely on using things like Asterisk to forward traffic and simply wait until all the broken routers disappear. With the advent of more and more P2P applications and the popularity of using UPNP to open ports on routers, it's only matter of time before this fixes itself. But in the meantime, we choose not to make a client that will work in all circumstances the way that Skype does.
Finally, on the quality of Skype's codecs. My understanding is that Skype at one time used the GIPS codecs and RTP libraries. I've used them myself and they are definitely extremely good. Just googling them now, I was interested to see that Google has acquired GIPS. I wonder if they would consider open sourcing those libraries... But you are correct. It's just code and free software writers can do just as good a job as GIPS. The current codecs and RTP implementations are actually quite good from my perspective, but possibly don't have quite the same performance on lesser hardware.
Anyway, you are correct that it isn't hard to put all the pieces together to create a Skype like product. There are actually several out there. The problem is that we have to wait for the NAT problem to sort itself out. Before that happens we won't have a competitor to Skype.