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, Insightful)
Absolutely!
It is indeed the very large user-base of skype that makes it so valuable (associated with its protocal closeness). Not only that but also the skype-in service which allows me to be able to answer my calls wherever I am in the world. I didn't see that service in the comparison. Even though there may be similar SIP-based services out there, they are unlikely to have all the characteristics of skype. So for now, a true substitution of skype would consists of several packages.
I use skype for a bunch of things, not just skype-to-skype, but sending SMS, calling out to "real" phones, and last but not least skype-in. The latter feature means that I cannot get a substitute. So for now I keep using skype, if it disappears from Linux I will have to use it on a VM. It is a killer app, and it is worth all the 8.5 billion that MS paid for it (really much more useful than office).
Re: (Score:2)
I just want to second this; I've been looking for a Skype replacement for about a year now, and the only thing I can find that will get me a softphone with a real number is Google Voice. While their web version works well, the lack of a client hurts. Even if I do find something that works, getting it to work with my phone sets (USB adapter) is going to be tough. Does anyone have any suggestions?
Jitsi (Score:2)
What's wrong with Jitsi [jitsi.org]? It looks good to me.
Re: (Score:2)
As for other alternatives, there's many that wont support ZRTP. People got to realize that listening to a SIP call is really trivial using wireshark (it
Re: (Score:2)
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.
Re:Sky .NET (Score:5, Insightful)
Here's the current situation:
- Email works everywhere. There's no "Microsoft email vs Google email" problems. You have an email account, you can send and receive email from other users with an email account. It's all compatible, world-wide.
- Instant messaging doesn't work everywhere. AIM, MSN, ICQ, SMS... all incompatible. It's a mess.
- Voice calls doesn't work everywhere. Skype, Google Voice... all incompatible. It's a mess.
- Video calls doesn't work everywhere. Skype, Facetime... all incompatible. It's a mess.
If we can't even agree on a standard for even text messaging, forget about voice calls and video calls.
What we need to do is agree on a standard that can do all this: text messages, files transfers, audio calls, video calls, from one to multiple users for each of those.
Re:Sky .NET (Score:4, Insightful)
You are right, but there is a timing for an open standard be successful, and skype just managed to get so widespread usage that any open standard will be sidelined as long as skype does not want to play ball. I'm afraid to say that this purchase was a bright move from the Redmond dinosaur, perhaps there are still people there with brains...
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: (Score:3)
Don't we have UPnP for this?
Re: (Score:2)
Interestingly, it appears as if there may be some further movement in the Facetime specs coming soon. See the speculation here:
http://www.subfurther.com/blog/2011/05/10/long-past-time-to-open-facetime/ [subfurther.com]
Re: (Score:2)
Moving to IPv6 isn't a solution - it's not like everyone's going to run IPv6 without a firewall.
Removing NAT from the equation (which is inherent in moving to IPv6) _does_ make everything much easier. There is no requirement to run without a firewall or even poke holes in your firewall for inbound traffic - UDP firewall traversal is completely reliable if you're not going through a NAT. The reason why things get unreliable when NATs are involved is because the software has to make educated guesses about things like what IP address and port numbers the traffic is going to appear on once it exists the
Re: (Score:2)
I think that's because of two reasons:
1- it's hard to make money while being open. Huge investments are required (development, hosting, deals with telcos...), and by definition you get no lock-in. I'm not sure how anyone can do all that, especially since most of those are up-front costs, and still hope to make money or at least convince investors to fund the start up. Few companies have the money without need for anyone (Google comes to mind)
2- proprietary does move faster. Apart from Google seeming to be a
Re: (Score:2)
What we need to do is agree on a standard that can do all this: text messages, files transfers, audio calls, video calls, from one to multiple users for each of those.
Unfortunately it doesn't help if we agree a standard. We also need to get enough people using the standard for it to be a viable competitor to Microsoft. All the people I want to call abroad are on Skype and will stay on Skype unless they have a reason to move. And none of them consider "It's Microsoft" or "There is an alternative" to be a reason to move. They'll stick with what works for them.
Re: (Score:2)
Actually, things are moving in the right direction. Apple, Google, AOL and Facebook are all using XMPP. Yahoo and MSN are the two big holdouts.
Re: (Score:2)
Can you send a message from Google's XMPP servers to Facebook's XMMP servers? Last time I looked at it, although the protocol was the same, the servers were closed boxes.
You can send messages from Google's XMPP servers to any XMPP server that supports s2s connections (i.e. practically all XMPP servers) and vice-versa. This has been true for years.
Unfortunately, Facebook's half-baked implementation doesn't support s2s, so is, indeed, a closed box. I will leave this to your imagination whether this is a strategic method of locking users in, or just that their developers did a half-arsed job (no idea why they insisted on writing their own implementation instead of using one
A social semantic desktop? (Score:2)
http://www.semanticdesktop.org/ [semanticdesktop.org]
My own limited attempts in that direction:
http://sourceforge.net/projects/pointrel/ [sourceforge.net]
Re: (Score:2)
There are no "Linux developers" involved, most of those programs work on other platforms and have nothing special to do with Linux or with "Linux developers" lack of understanding.
Re:Sky .NET (Score:5, Insightful)
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.
Curiously, I have never done so. I have only used Skype for calling other Skype users, including video calls and conference calls. It's an attractive value proposition when transatlantic rates would apply to regular calls.
Basement geeks probably don't understand it, but that's what most normal people use Skype for.
What does "normal people" mean here? I'm middle-aged and married with teenage kids. We own our house, cars, etc.
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".
Maybe not, but interconnectivity is a requirement for any solution which hopes to "win", or even to endure in the game. Consider regular telephony or mobile telephony. It does not matter whether your equipment is ancient Bell stuff, or whether it's a GSM or CDMA cellphone: they all interoperate seamlessly. That's what's needed from Skype and from anything else which hopes to compete. And Skype won't get there unless it opens up. When it opens up, there will be interoperable alternatives.
The walled garden approach does give a first-mover advantage, but this can later turn into a handicap.
Re: (Score:3, Funny)
What does "normal people" mean here? I'm middle-aged and married with teenage kids. We own our house, cars, etc.
You're posting on slashdot. This precludes you from being normal.
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
Re: (Score:2)
Re: (Score:2)
Wait a minute. A geek says he wants to use Skype? Oh, man, I just got an image of some geek mutant tard in his basement doing a Skype video call with anyone... GROSS.. (Shiver), Just the thought goes way past giving me the creeps, and the images that come to mind...
I am going to need years of therapy for that one.
Can you just imagine? SEEING slashdot regulars? Oh, man, we need fed regulation to limit nasty lookers/losers from using Skype video...
Re: (Score:2)
...(it runs on everything)...
Not for long I'm afraid.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
I disagree. Google Voice - although non-free - gives you a phone number that can map to your google talk account, and Google Talk servers are federated. This makes XMPP and Jingle a viable competitor to Skype with features analogous to Skype-to-Skype and Skype-In. You just need to be able to "Talk out" - which you can do from the Gmail interface. Call and video quality are comparable as well.
Jingle needs clients on more platforms, but I can see it as a viable competitor to Skype.
Re: (Score:2)
Re: (Score:2)
Not entirely. I have no need or desire to use Skype to call landlines or mobiles, or vice versa; but I do need to call other Skype users and they me, and to conference-call them.
What the developers have missed is that we need a single way to create a SIP ID, a single global directory, and a single global ID/addressing format. Until this is addressed, SIP is a dead duck.
Re: (Score:2)
What the developers have missed is that we need a single way to create a SIP ID
Well you can't really have that any more than you can have a "single way of ordering a phone line" when there are multiple service providers. I guess SIP could introduce an account registration system like XMPP has so you can register accounts directly from your client, but is it really that hard to register on the service provider's website, like you do for most other services such as email?
a single global directory
I'm not sure how that would work - you really want a list of billions of people? When you want to phone Joe Bloggs,
Re: (Score:2, Flamebait)
None exist. (Score:5, Insightful)
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).
Re: (Score:2)
> It doesn't support 1/16th of Skype's vital features, and it doesn't even support video in the desktop client.
I never undestood why Google from the beginning refused to build video into the client. As I remember, the party line back then was that video was "bloat", and that they did want the GTalk client to remain "simple". And it remained half-assed. And then they gave up any further work on it. No video, no Linux/Mac versions, no conference mode, nothing. Half a decade passed and all they had to offer
Because the desktop is history for Google (Score:2)
The official platform for Google Talk is not Windows or Mac, it is GMail.
The GMail Google Talk client is the one with the most features. Which makes sense, considering that it will be the client their ChromeOS runs.
Now that Android supports native video in Google talk for both 2.3.4 and honeycomb, I expect a renewed push for video in all Google Talk clients. However, I also never see the desktop client matching the GMail one for features.
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: (Score:2)
Not affiliated with this site, but I find it handy at times:
http://alternativeto.net/software/skype/?profile=linux&platform=linux&exactmatch=true [alternativeto.net]
Re: (Score:2)
>> The current Skype client for iOS, Android, and Linux sucks. The current OS X client is very poor.
Skype for iOS works great. What do you want? Skype for Linux is a bit clunky, but not bad considering how small that market is and the fragmentation. Same goes for Android (fragmentation making development difficult).
The OSX client works great. The 5.x series is essentially up to par with the Windows client.
Re: (Score:2)
Re: (Score:3)
Gmail chat supports video on the desktop via a browser plug-in, even in Linux. If you have some aversion to using your browser as a client, Pidgin nominally supports video calls over Google Talk, although it causes a crash in my admittedly outdated version of Pidgin.
Re: (Score:2)
The entire VoIP/video chat market is a cesspool of junk.
Amen.
I had a Nokia N800 a coupla years ago (wonderful machine, pity Nokia screwed it up), and I ran Gizmo, got myself a Gizmo ID, even paid for some external call connectivity (first and last time I ever needed to). I also installed Gizmo on my laptop and desktop.
Crap all round. Dire interface. Crackly, stuttering voice no matter how good the bandwidth. As others have said, the reason people use Skype is it works.
Does no one remember Speak Freely? (Score:2)
http://www.speakfreely.org/ [speakfreely.org]
I made many international 'telephone' calls long distance free over a crappy 56k modem using this software. I'd lost the need to use it and moved to windows.
Development ended in 2002. Pity.
Comment removed (Score:3)
Re: (Score:2)
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...
I have a secondary, small desktop box specifically for applications where a Windows environment is required, like your situation: Skype, MS Office Suite, Adobe Acrobat Pro (the real deal, not the reader), MSIE for any web site that seems to be behaving oddly with FF on Linux (including 99.5% of my bureaucratic overhead), etc. My primary workhorse is a Linux box, but because of job-related issues, I am inescapably tied to the Windows experience.
Re: (Score:2)
Re: (Score:2)
But if they used standard SIP technologies they wouldn't be where they are, because people would be having problems getting through their NAT routers. Skype took off because they made it easy to set up; SIP just doesn't have that.
Re: (Score:2)
Re: (Score:2)
Nokia is failing in the same way as Microsoft is failing. They're having trouble keeping up with nimbler rivals but they are still immensely profitable. Just because they're not doing well in the US market doesn't mean they're about to go bust. Far from it.
Re: (Score:3)
Re: (Score:2)
I agree that those programs are no true alternatives, not until all my customers, my coworkers and my friends start using them. They'll stick to Skype and so must I. If they'll stop developing the Linux client and make the current one incompatible with the other ones I might even have to buy a Windows netbook only for it. At least I'll test web apps with IE9 outside a VM. I guess I'll become a heavy user of Synergy [sourceforge.net]
By the way, I definitively switched to Linux at the time of Skype 4, with that big bad full s
Re: (Score:2)
Nokia are and were failing because Symbian is a steaming pile of horse shit. It's slow, buggy, feature poor and generally an abomination. They made great simple phones and still do, but their smart phone line is awful. Symbian 60 phones aren't as powerful or reliable or feature rich as the iOS,Android,WIn7 phones and they're not as simple or reliable as Nokia's old phones. The only reason they sell at all is that they're a third of the price of their competition. The company was mismanaged, the code base wa
Re: (Score:2)
You misunderstand the technologies at play here.
Did you respond to the wrong post? What evidence is there that he doesn't "understand the technologies at play here"? What he's saying is a perfectly valid reason why he can't use any of the "alternatives" and that reason has nothing to do with technology. It has to do with the fact that his company has standardised on Skype, and because his relatives, on the other side of the world use Skype. Skype is synonymous with "video chat"/"internet telephony" for all the non-technical people I know and it has such
Off-topic: Windows Video Client (Score:2)
Does anyone know of any good free video conferencing software for Windows? Skype recently decided to charge for video chatting with more than one person at time.
Pick up the phone... (Score:2)
Re: (Score:2)
Precisely. The use cases for which VOIP makes more sense than a conventional land line are vanishingly small.
Skype does have some advantages over conventional operators in certain niche areas where Skype can be more price competitive.
Raise your hand... (Score:2)
...if you've had someone ask you with a straight face "..if you know of a good voice chat application for mobile phones."
Now, I know that this can be asked seriously in a specific way (ie, SIP specific, or "free" or whatever) but it still seems to suffer from a large amount of irony.
Empathy and Google Talk / Chat / Voice (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
flash changes should have no effect on the driver side of things.
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.
Re: (Score:2)
Same here, I haven't tried Ekiga in a while, but when I tried it, it always was kind of garbage, hard to setup, didn't work half the time and when it would worked the sound quality was awful. The only good voice chat thing I have seen so far on Linux is Mumble, the sound quality is amazing, you can have conferences with multiple people, etc. It is a fantastic tool, the only big show stopper with it is that it is more IRC with voice then it is a Skype replacement, so setup and use isn't exactly easy.
Re: (Score:2)
Re: (Score:2)
Agreed. I tried to use Ekiga when I was on business trips to talk to my family. I'd boot up on a livecd (couldn't install on company hardware), install it, and try calling home.... video wouldn't work.. or audio wouldn't work... or both. I never once got it to work right. I gave up. I bit the bullet, and installed Skype. It works.
My parents and family across the country installed it... it works. We can video chat with them. They love it, the kids love it.
And if I may... how about we come up with som
Re: (Score:2)
There are many SIP clients that are better than Ekiga. I have never gotten Ekiga to work and I definitely know what I'm doing (implementing SIP software used to be my job). I use Twinkle. It's ugly as sin, but it works.
When both sides are behind NAT, you may get one way audio, depending on the router that's doing the NAT. This is a problem with the router and even STUN won't solve the problem (ICMP packets bind the port, so if you receive a packet before you send one, your network facing port number wil
Useless (Score:2)
All of these "alternatives" are pretty much useless to anyone who used Skype to call land-lines overseas from a country other then the US.
Sure, there are million and one of peer-to-peer "chat" apps, ranging from text only to full video. But its all pointless if the other end has just an old plain telephone and the going long-distance rate is $4 a minute.
That is why Skype is a huge deal for a lot of people. Software "openness", while very nice, does bring very little to the table where the functionality is
Re: (Score:2)
Google Voice is problematic "from a country other than the US".
Jitsi (Score:5, Informative)
Jitsi seems to be developing quickly and has proven rock-solid for me in daily use.
Self Profiling prophecy. (Score:5, Insightful)
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.
Re: (Score:2)
On the other hand, it's not hard to imagine a future with millions of cell phone users Skyping each other...on WM7 phones.
To be continued...
Re: (Score:2)
The Linux client and the Android client likely have no more in common than the OS X client and the Windows client.
It's more accurate to speak of Android and Linux as two separate platforms for Skype than to imply that Skype on Android has any impact on Skype on Linux.
Missing the point (Score:2)
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.
Backwards compatibility? (Score:2)
That said, MS still wants to make money. If they can keep customers around, they will. It isn't in their own best interest to drop Linux development of Skype, because the Li
Re: (Score:2)
> That said, MS still wants to make money. If they can keep customers
> around, they will. It isn't in their own best interest to drop Linux
> development of Skype, because the Linux users likely won't go out
> and buy a version of Windows to use Skype in the future; hence they
> become lost customers.
You could say that about any of the products that microsoft has bought and then dropped, or seriously curtailed, support for other OSs. Losing the customers and money won't stop them for a second i
Google Voice + PBXes (Score:2)
If you create a PBXes account, you can have it act as a client for Google Talk. Then you can connect to PBXes using any SIP client, and make and receive calls through your GV number.
Skype v SIP (Score:5, Insightful)
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.
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.
Re: (Score:2)
Why would open source writers think using another consenting computer's resources "evil"? P2P does it all the time and no one thinks anything of it.
Because they're telco types at heart, not infosystems types. Different communities have different standards of acceptable behavior. (The interesting thing about Skype is that its developers were enough in tune with both sides of this particular debate to understand the technology of IP telephony and implement a workable solution for the show-stopper problems.)
Re: (Score:2)
As the introvert geeks we are, do we really need it at all?
Do you use Linux for work? Remote work?
Re: (Score:3)
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.
Re: (Score:3)
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 i
Re: (Score:2)
What?
Re: (Score:2)
Re: (Score:2, Insightful)
That's, in large part, the fault of Linux not having a lot of standard features that Windows and Mac have. By that, I mean there are 20 competing technologies for things that are standard on Windows or Mac.
The fact that you can replace your GUI with something else is great, from an end user perspective.. but terrible from a developer perspective. You have to have a base set of features you can rely on, and LSB isnt' anywhere close to that. Take, for example, desktop compositing. This is something that a
Re: (Score:2)
The fact that you can replace your GUI with something else is great, from an end user perspective.. but terrible from a developer perspective.
How so? I can write my app with GTK or Qt and as far as what "GUI" someone is using, it will work on 99.9 percent of Linux desktops. If it doesn't, it's because that person really doesn't want it to work.
Take, for example, desktop compositing. In Linux, it might or might not be there, and if it is there, there might bet half a dozen different API's.
What are you talking about and pray tell what way does this impact me as a developer? Are you saying I need to interact directly with the compositing engine? Because I don't. That's absurd unless I'm specifically targeting that with my application. Are you confused?
Beryl
is installed on nobody's computer as
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.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
YMMV but overall lately(5+years) I have been getting very very good mileage on my Linux installs.
Re: (Score:2)
Man, Swype is a bitch to learn, ain't it?
Re: (Score:2)
SIP and H.323 are fine, but they are only part of the issue. Codec's are a huge problem. The free (as in no license required) codecs are bandwidth hungry.
The real issue though, is one of configuration. Using a strict SIP or H.323 client means the user has to understand issues like addressing, ports, etc.. This is fine for geeks, but end users want a point and click, it's done kind of system. That means having a central service that not only provides default configurations and service, but address books
Re: (Score:2)
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: (Score:2)
SMTP, but not in the first few releases of Exchange :)
Re: (Score:2)
Yes [microsoft.com] (it even mentions Linux on the page). Though the definition of "native" in this case is arguable.
Here [microsoft.com] is another thing.
Re: (Score:3)
Except when they voluntarily pay more than Windows users for the one of the few decent, paid applications that run on both.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The FaceTime protocol is partly based on numerous open industry standards.
And yes, that includes H.264 and AAC. Whole industries are based on these standards, just get a cash pool going, get the damn required licenses and get with the program already.
As does Google's which is based on XMPP. But without the patent hassle.
Re: (Score:2, Offtopic)
Two girls and one cup.