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?"
Ekiga? Don't make me laugh. (Score:4, Informative)
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.
Jitsi (Score:5, Informative)
Jitsi seems to be developing quickly and has proven rock-solid for me in daily use.
Re:Sky .NET (Score:5, Informative)
I think the VoIP standards were available before Skype made it big. Heck telephony over the internet was around since hte early 90's, even encrypted (PGPfone anyone?).
No, the reason Skype worked was it ... just worked. No crappy port forward configurations in the router, no dozens of firewall settings need to be changed, etc. It. Just. Worked. You started it up, it ran.and connected.
Sure NAT and STUN are hacks, but they do work through most firewalls just fine, and Skype's architecture ensures it can get through firewalls easily enough.
Moving to IPv6 isn't a solution - it's not like everyone's going to run IPv6 without a firewall. And convincing Joe Average to figure out how to configure their router to let IPv6 through for their SIP phone... not happening.
Hell, Apple, release the FaceTime specs already as well - it too Just Works(tm) without firewall configuration.
Re:None exist. (Score:5, Informative)
http://www.google.com/chat/video [google.com]
Best part is it you can voice/video chat with non-google users including non-google jabber servers with Empathy
http://live.gnome.org/Empathy [gnome.org]
http://en.wikipedia.org/wiki/Jingle_(protocol) [wikipedia.org]
Re:Already Neglected... (Score:4, 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.
Pretty damn close to perfect response (Score:5, Informative)
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.