Slashdot Mirror
Linux-Friendly Alternatives To Skype
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?"
I don't think Linux developers understand the problem. Once again. It's not about the technology underhood or that the protocol is open. The fact is these things need to be able to call to the "real world" and be able to receive calls from there. Basement geeks probably don't understand it, but that's what most normal people use Skype for. It will also need clients on tons of mobile phones AND it needs to be able to be used with Skype users. Now that Microsoft owns part of Facebook they will probably start using Skype too. You won't win this just because your application is "open".
The entire VoIP/video chat market is a cesspool of junk. I'm talking about all platforms, all manufacturers. Skype is the "least bad" of the very few even notable pieces of software. However, let's not pretend Skype wasn't terrible in every incarnation except the Windows client, and even then still buggy or poorly designed.
The current Skype client for iOS, Android, and Linux sucks. The current OS X client is very poor. The Windows client works most of the time at least until the next software update and then all bets are off.
So what does that leave us with? Live Messenger? Facetime? Neato.
Please be quiet about Google Talk. It doesn't support 1/16th of Skype's vital features, and it doesn't even support video in the desktop client. Plus the few telephone options it does have are US only.
I'd love to see this market seriously shaken up. I want to see massively better business apps that can replace your entire Cisco telephone system, and personal apps which make the teenage girls drool (since I assume that is what Live Messenger is aimed at).
I work from home, in another country, at 1500 kilometers distance from my colleagues. Sure, I could TRY to convince the company to switch to a completely different application that is incompatible with skype, just because I want to use Linux. Or ask my relatives who also live that far away, to do that. But somehow I don't see it happening...
Here's the secret to immortality:
Actually, this is not entirely true. I've managed to get my Skype account deleted definitively exactly today, but I'm using Empathy 3.x since a couple of weeks to make daily voice and video calls. Video is actually a bit shakey, but voice is okay. This is for the on-line VoIP part. There have been pointers that Empathy might be estended to support landline calls too, it's just matter of time.
42.
With a heavy heart I have to say that Ekiga is a piece of junk. I say this without any exaggeration.
For a while I've been trying to avoid Skype and get my family to use Ekiga. (My family already runs Linux.)
I've been trying to get Ekiga to work in various environments for at least three years. I've tried on two Linux end-points, two Windows end-points, and mixed. It works maybe 10% of the time -- and even then, not for long. Other times, the two participants cannot see each other online -- or can, yet cannot send messages to each other. When one side calls the other, the call looks like it's going but nothing happens on the receiver's end. Or, it immediately resets on the sender's end.
The biggest public argument against Ekiga -- lack of interoperability -- was never an issue for me! My family was ready and eager to use the latest (2.x, later 3.x) Ekiga. Yet my diehard open-source ways greatly failed this time.
Yes, both sides are behind NAT. That's the way of life. Skype works on today's Internet; Ekiga doesn't. End of story.
I've been checking out the http://jitsi.org/. It used to be SIP Communicator, but has added support for all common IM protocols. It does video calls and desktop sharing over SIP and XMPP. The only disadvantage I can find is that it is does not work with ekiga.net (because ekiga.net uses a not-recommended method of NAT traversal).
Jitsi seems to be developing quickly and has proven rock-solid for me in daily use.
Microsoft buys Skype.
Linux users ditch Skype
Microsoft sees very little Linux Skype usage so drops it from development.
Linux user assert their fear that Microsoft will drop all Linux apps it purchases.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Except when they voluntarily pay more than Windows users for the one of the few decent, paid applications that run on both.
Dilbert RSS feed
People use Skype because other people use Skype.
How can anyone believe any of these are viable alternatives if they don't connect to the Skype network? Do the proponents truly expect everyone currently using skype to suddenly switch to one of these "alternatives"? I think not.
All the while most people are using Skype, most people will continue to use Skype.
That was my thought, I'm not sure where I'm going to be working next, but it's definitely possible that my next job will involve the use of skype on a regular basis. In my personal life I rarely use the phone for actual talking, usually it's checking the email, looking up information or texting, but I do have voice service and use it from time to time.
I'm working at a place where I have to co-ordinate with somebody in another state. We're using Skype and here's a few reasons: (note: It is not my intention to imply that these features are exclusive to Skype.)
- Video chat- We do communicate a little better when it's more face-to-face than over the phone or via text. It does audio or just plain text chat, too.
- Screen sharing- We can show each other what's going on on our desktops, lots of what we do is visual so that helps.
- File xfers
- Clients for iPhone, iPad, Mac, and all the features still work- I've heard it works on Android too but I personally have not seen that.
- No Firewall BS
- Encryption- Supposedly the Skype connection is all encrypted, including with file x-fers. That makes our overlords happy.
Hopefully this clarifies why I asked about remote access.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
I have felt the same way, but I think it's a blessing.
On linux, the UI has remained simple and usable, whereas on other platforms everyone gets to be guinea pigs in the develoers' horrible window-management experiments, and cruel abuse of white space.
Just another proletarian malcontent.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
We make not see a Open Source replacement for Skype. But all of the reasons I see given here are just wrong.
Most of them blame SIP for being hard to set up or incompatible with NAT. These things have nothing to do with SIP. SIP is just one part of a rather large tool box needed to build an internet phone. SIP is actually a small part - the bit that handles the negotiation between the two ends over how to send the voice. It does not send actually send the voice - it leaves that job to another protocol, RTP. It doesn't even negotiate the codec - SDP does that. It does not resolve domain names - DNS does that. It does not pierce NAT - STUN does that. It does not do auto-configuration, but any number of SIP based phones out that can pull down their configuration information from a URL. Blaming SIP for not doing these things is like blaming a car engine for not coming with a fuel tank. You are blaming the wrong thing. Blame the person who designed the phone that uses SIP for not providing those things. Don't blame SIP. It has nothing to do with SIP.
I'd bet SIP is used to make far more calls in any given day that Skype is. SIP is used as the basis of all IP phones out there - Cisco, Polycom and so on. IP PABX's are now a common feature in most enterprises. They have gradually replaced the old analogue PABX's, so many business calls have some leg passing over a SIP connection. Also, if an ISP offers VOIP they will invariably do so using SIP. Which just goes to prove what I said above - people are using SIP phones every day, without problems, in fact without even realising it is a SIP phone. They just pick up the handset and dial the number, or more likely touch the softbutton besides the persons name. It's actually easier than using Skype. They can do this because it is possible to set up a SIP phone that just works - just like Skype does.
Which of course proves it is perfectly possible to design a VOIP system based on SIP that is every good as Skype. For people saying "what about Skype's fantastic codec's", Skype has done great work with codec's. But there are free ones out that almost as good, and besides Skype publishes their codec algorithms. To put together a Skype like system that used SIP isn't technically hard. A SIP softphone on all major platforms (including all phones) that automatically downloads its configuration from their servers would be one piece of the puzzle. So would maintaining a set of whitepages of people who use the system - just like Skype does. And a STUN server. And a messaging server. And a call test service. And purchase connectivity to all the existing telco's out there, so you can interact with the real phone system. The list goes on and on.
But that probably isn't going to happen on the scale Skype has done it. The reason is simple: sure open source can provide the software for free, but it takes real money to set up and run the rest of the infrastructure. So far it everyone who has done it has lost money, Skype being the leading example. It has bleed money since its inception, so much so that the media has had a field day questioning Microsoft's sanity for paying $8 billion for it. Given its history, what sane person would want to go try and build a new Skype ecosystem? The answer is no one - which is why there won't be an open source equivalent of Skype any time soon.
I was going to say the same thing. What features am I missing? The big page of adds?
ZRTP is off limits to most clients since Zimmerman has made the license so restrictive AND EXPENSIVE that commercial vendors simply aren't interested in it.
SRTP is utter rubbish and should never be bothered with. Oddly, I happen to know that the video conferencing systems used by most governments are "secured" by it.
RTP is a weak protocol at best. The only advantage of it (as I'm programming a TS over RTP mux) is that it is common. Even with RTCP additions, bidirectional clock synchronization is rough. Additionally the granularity of ACK/NACK as an after thought was a mess. In the case of video conferencing, being able to perform pure predicted video unless a new intra is requested is a must. The latency of RTCP in this scenario is too long. Also, the sequence counter of RTP is so damn small that when transmitting high bit rate video over UDP, it's entirely possible a 1 second network dropout can go entirely undetected/corrected.
Forward error correction, a damn near minimum requirement of block based codecs in audio/video is a joke with regards to RTP as well.
Skype was beautiful since instead of focusing on inter-op with crap standards like SIP, which are either too damn big to effectively implement (H.323 for example) or too damn small (SIP) to be useful, they instead hacked their own protocol which included just about everything good.
As a further note, Skype is wonderful because it is by far the best in class for acoustic echo cancellation in free software. PC's suffer the terrible flaws of imprecise timers (floating clocks, cheap crystals, etc...) and very often unpredictable I/O latencies (on systems where ASIO hardware is not available, meaning 99.9% est.), crap speakers, crappier microphones etc... Without using a hardware based acoustic echo cancellation system or isolating the microphone from the speakers eliminating the need for AEC, it is very hard to achieve in software. You need to :
a) identify the clock rates of the audio output and input constantly as their crystals can be drifting differently
b) rate convert the input or output stream
c) search the input stream for the output stream in order to synchronize clocks
d) adjust levels of the input or output
e) subtract the output from the input to cancel the echo, hopefully removing some added noise due to low quality components in the process.
Oddly, adding a high quality microphone to the webcam you bought amplifies the problems substantially and even removes your ability to adjust the microphone location as the camera needs to remain focused. The added USB latency makes the problem even worse.
Additionally, if there's something more than just your conversation coming from the speakers, there's even more to be done to alter the definition of the output audio in order to remove the echo of that additional noise as well. It requires the AEC code to "read the output" back from the audio subsystem instead of using the audio it sent to the subsystem.
This task is insanely complex in software and uses an insane amount of CPU. "The Good Stuff" meaning the expensive software from certain vendors (of which I worked for one) requires more CPU power to process just the AEC than was required to handle H.264 encoding AND decoding at 720p. And still we couldn't reliably handle more than just 12Khz signals on a Core 2 Duo 1.76Ghz.
So, if we looked at it from purely a technology perspective, the closed/proprietary systems are very likely better solutions than the open and standard compliant systems as there is SOOOO much room for improvement that the standards based systems can't compete.
From a business perspective, Skype has the majority of the world's chat messenger and voice chatting users. When granny wants to video chat with her little grandchild, she Skypes them. If you buy a notebook with a camera, it's a Skype compatible camera that matters. If you buy a webcam, it says Skype on the box.
Converting that many users to something new is pretty much out of the question.