Microsoft cuts Asterisk ties--What are the open source Skype alternatives?

No readers like this yet.
Different cell phones

Opensource.com

Microsoft has ended its deal to let the open source Asterisk PBX system work with Skype as of July 26, perhaps due to the launch of its own competing service.

When Microsoft paid $8.5 billion for Skype two weeks ago, they promised to hold it as a separate division and continue supporting non-Microsoft platforms, but users have been skeptical. It didn't take long for the tune to start to change. Maybe somebody should have asked for a pinky swear.

Where should an open source user turn instead? Earlier this week, the GNU Project announced GNU Free Call as an open source alternative, even calling Skype out by name in the project's mission:

Our goal is to make GNU Free Call ubiquitous in a manner and level of usability similar to Skype, that is, usable on all platforms, and directly by the general public for all manner of secure communication between known and anonymous parties, but without requiring a central service provider to register with, without using insecure source secret binary protocols that may have back-doors, and without having network control points of any kind that can be exploited or abused by external parties. By doing so as a self organizing meshed calling network, we further eliminate potential service control points such as through explicit routing peers even if networks are isolated in civil emergencies.

We do recognize this project has significant long term social and political implications. It also offers potentially essential utility in public service by enabling the continuation of emergency services without requiring existing communication infrastructure. There are many ordinary public service uses, such as the delivery of eHealth services, as well as medical, and legal communication, where it is essential to treat all with equal human dignity by maintaining privacy regardless of race, religion, or political affiliation. Equally important is the continuation of emergency medical services even when existing infrastructure is no longer available or has been deliberately disabled.

But GNU Free Call is the future, not something you can use today. And even though Skype was never exactly open source itself, more and more open source fans seem to be looking for ready alternatives that aren't under the Microsoft umbrella.

These are the suggestions I've seen come up on various message boards and blog posts. I haven't heard of any yet that are as user-friendly and ready-to-go as Skype. But I also don't have any experience with any of these, so I'd be interested to hear your opinions on any of the following or others that you like.

  • Ekiga: Formerly GnomeMeeting
  • Blink: VoiP calls, video, and chat 
  • Jitsi: Also supports XMPP, AIM, and other IM services
  • SylkServer: SIP server and conferencing
  • SFLphone: Enterprise softphone for desktop and embedded
  • Linphone: VOIP client also available for Android, Blackberry, and iPhone
User profile image.
Ruth Suehle is the community leadership manager for Red Hat's Open Source and Standards team. She's co-author of Raspberry Pi Hacks (O'Reilly, December 2013) and a senior editor at GeekMom, a site for those who find their joy in both geekery and parenting.

22 Comments

it seems i'm going towards Blink...

This came up on a mailing list as well: Skype is a network, a client, and a protocol. There is nothing globally available to consumers which competes for ease of use, reach, and that Just Works (most of the time) because no-one else offers the full stack. The items you listed above are merely clients, they require a network (Ekiga provides a service, but it is not reliable).

GNU Freecall may take off, it may not - it has a long way to go.

I would suspect one or several of the mobile phone-based services can expand their reach to other devices; services like Fring have the network and the client for mobiles & tablets. With the proliferation of smartphones already having viable alternatives to Skype on mobile, and consumers being familiar with them, it would be easy to move.

All that said, I doubt MS killing the Asterisk integration will matter to the general consumer.

To be a Skype-killer, the service must offer:

1. Fantastic quality. SIP over the Internet does not match the quality of Skype.

2. Excellent cross platform support and the app must be be really simple to install and configure. Admittedly Skype on Linux is vastly inferior to all other Skype clients.

3. Really simple conference call setup.

4. People are increasingly using Skype for purposes such as screen sharing, that is also very easy to setup.

5. Less important, but Skype chat is a really good chat system.

6. Video support will become increasingly important.

Unfortunately none in your list come close to even matching Skype for voice quality. But I look forward to the day when there is an open source equivalent that offers all of the above.

The only point you make that reflects reality is 2. But I'll address them all.

1. SIP has a wide range of codec options with varying quality (and bandwidth usage). Many open codecs have much better quality than Skype, many have worse. I get comments to that effect ("Wow! Your voice is so clear!") from Skype users when I call them landlines via Ekiga and a SIP callout service (diamondcard.us). Your experiences with poor voice quality have nothing to do with Skype vs SIP and everything to do with the codecs supported by both endpoints. Of course, Skype has its own proprietary codec, and it is decent, but is not the best by any means (for either bandwidth or quality).

2. The big problem with SIP is NAT. SIP *would* be extremely easy to set up if it didn't use multiple ports and also have to deal with NAT. (SIP clients are already cross platform and easy to install.) I wince as hundreds of first time users on the Ekiga forum are turned away because of frustrating NAT issues. Solutions to this are:
a) VPN. I use SIP with family and friends via a private VPN that I set up (openvpn). There are fine VPN programs for Windows as well (including openvpn). This bypasses NAT issues for those on the VPN.

b) IPv6. No NAT issues when both ends have an IPv6 address.

c) IAX - Inter Asterisk eXchange protocol - this multiplexes the many ports used by SIP and RTP/sRTP into a single UDP port that traverses NAT with ease. Only a few clients support this at present (Ekiga does not).

d) sip proxy - the technically savvy can run a sip proxy on their gateway linux server. This essentially provides smart protocol aware NAT for multiple simultaneous SIP calls through a single gateway IP. The less technically savvy can purchase a router like box (personal PBX) for $500 - $1000 that provide sip proxy for internal smartphones, and some telco ports for trunks and POTS extensions. (The box contains embedded asterix or equivalent.)

3. Using one of the many free SIP conferencing services is easy as dialing the same room #.

4. SIP does *not* support screen sharing, not should it - there are so many good ways to do screen sharing. Bundling it with Skype just rubs in the security risk that Skype presents - you are giving all other Skype programs on machines all over the internet the equivalent of ssh access to your machine. Anyone that "cracks" the Skype binary has free access to all those Skype using machines. (In this case, I sincerely hope that Skype is really really difficult to crack...)

5. SIP is also a really good chat system

6. Video works great too.

I wonder why in all I have read so far, everybody seems to focus on SIP as the candidate alternative to skype. I understand that SIP has been associated with VOIP for quite some time now.

But another kid on the block is worth investigating too in my opinion: XMPP. Most people link XMPP only with instant messaging, but the protocol is open to voice and video as well, using the jingle standard.

And XMPP does have a network: Google Talk is based on XMPP as is, Ovi Talk, Jabber and many independent xmpp providers. The nice thing is that all these providers can connect with each other. So a Jabber user can communicate with a Google Talk user. This is a big advantage of XMPP over Skype in my opinion. While skype has a head start in popularity it is limited to only skype users. Once you are connected to an XMPP network on the other hand, you are suddenly connected to every other (public) XMPP network around the globe. A wonderful feature to avoid vendor lock in. I don't know SIP's capability in this respect. I know it also has interconnection capabilities, but I don't know if they are as powerful as XMPP's.

After I got word of the Skype acquisition, I looked around and installed Jitsi with a jabber account. I only have limited experience so far, but it seems to me it does have most of the features that make Skype so popular:
<li>Audio/Video calls</li>
<li>Conference calls</li>
<li>Instant messaging</li>
<li>File transfer</li>
<li>Screen sharing</li>

It can do this over SIP or XMPP. Additionally it supports some other IM protocols as well that I'm not really interested in.

I won't make any claims on the audio/video quality, but my first preliminary tests don't seem to indicate they would be any worse than Skype.

I am experimenting with the nightly build. Your mileage may vary with older version. It does have some rough edges still, but that is to be expected for a beta release.

My biggest hurdle will probably be to make my Windows using contacts understand that I may not be able to use Skype in the future anymore and to have them try another network and the Jitsi client.

In general I feel that both SIP and XMPP hold a great promise to become the basis of strong communication networks next to Skype and perhaps who knows even replace it in the future.

The thing preventing that right now is probably not the protocols, but the maturity and interoperability between different clients. Jitsi to Jitsi works fine in my experience. But I couldn't get Empathy to talk reliably with Jitsi, either over SIP or XMPP, while both claim to fully support these protocols. Perhaps that's just a configuration issue. Perhaps they fail to negotiate a common audio or video codec. It doesn't really matter as for an ordinary user the message is: it doesn't work. And that's bad.

I really hope the authors of all these different clients see an opportunity here and work together to solve these issues.

Until that time I will have to use a mix of a. Skype which will probably start to lag more and more on linux and b. agree with my other contacts to use one and the same alternative. Which one that will be is not completely decided, but Jitsi so far had most of my required and nice-to-have features covered.

Disclosure: I have no affiliation with Jitsi. I just discovered it recently, tried it and liked it so far.

Lets move to blink

Look. For people that want a service like skype, I don't think there is an alternative nor do I think there ever will be. It's sort of like saying that Mac or Linux will overtake Windows. While I love open source, I think it will always remain the little brother. With that being said, there are any number of services out there that will give you better prices and they will give you step by step instructions for a few popular free clients. I am not going to put any companies on here for fear that my post will be deleted, but I use a free client. I pay $0.99 a month for the American number, and $.009 a min for calls to the usa. For those quality people, you can get sip with many different codecs. Ad far as price goes, skype is $0.023 a min and $18 for 3 months of an incoming number. Real cheap and there are even ways to do it for free.

I want to add something before people blow up at me. Open source is better and much more powerful but it just isn't as popular. Whether it be ease of use or advertising or just people comfortableness, it is just not being used like it's proprietary cousins are.

It doesn't really matter whether your softphone is open source or proprietary - that is a personal choice. There are many fine commercial SIP softphones, as well as open source ones. And it matters even less when buying a piece of hardware - a SIP phone or personal PBX. It *does* matter when the protocol is secret and proprietary. This is the problem with Skype. Choosing the Skype service locks you into using their client (and vice versa).

One of the key features of Skype that I didn't see mentioned was the ability to call traditional phone numbers. I would think this service would be pivotal for use with Asterisk. What's more is that while you could use an open source tool to call traditional phone numbers, you are always going to need some form of service to make it work.

I am watching Google Voice as the alternative in that regard. I think I read that you can port telephone numbers to their service, and at one point, I found a tutorial for hooking it up to Asterisk. I haven't tried it, but I would love to hear others' feedback who have.

There are hundreds of (paid) services offering SIP to POTS that work with any SIP client. I won't mention names, just google "sip callout". That is the big advantage of an open protocol - choosing a service doesn't lock you into a client. (See the post on XMPP above - that sounds like an interesting alternative to SIP.)

Re. Google Voice: it is limited to US customers and use with Asterisk or other telephony software is not supported.
Both of these can be overcome but not by Joe OrdinaryUser, and Google can at any time break these workarounds.
So, even though I am a Google fan, this disqualifies Google Voice as a Skype alternative.

Google voice can be used every where. I use Skype and Google voice to call cell or land phone. Calling number with Google voice costs less than Skype, as for instance it costs 3 times less when calling cell phone in Vietnam however the quality is currently not as good as Skype.

oovoo as skype replacement.

http://www.oovoo.com/home.aspx

XMPP's Jingle protocol - which is an evolution of Google's V/VOIP services - is getting very close.

There's actually no magic in Skype, it's just a reasonably neat implementation of a voice network, and XMPP provides the decentralization and openness that makes it as practical and sensible to deploy as email.

There's SIP gateways about, too, for Jingle - SIP and Jingle are intentionally very similar - and there's also POTS callouts available.

There's also numerous clients - Jitsi, mentioned above, is one, but also Empathy (typically shipping with GNOME), Psi, and Gajim all support Jingle to varying levels.

The current blocking point is not actually the network of the implementation - or even the NAT problem, since STUN largely addresses that, even if we don't go the Jingle Nodes route - but the lack of an obvious candidate for "the" codec. This means that you can make calls all over the map, but you can't always send the actual voice.

I'm a little confused as to why the GNU Project is trying to push us down the route of a single implementation, yet again - really, the benefits come when there's solid open standards and interoperability, not a single working implementation. In the XMPP world, we have several implementations, so you can pick whichever you prefer. (And note, I've only mentioned the open-source ones above, with the exception of Google's implementation).

GNU is not trying to push a single implementation. They are pushing an open protocol - SIP, and getting market share requires at least one compelling implementation. XMPP sounds like good open competition to SIP - especially if it uses just one port. STUN doesn't *not* solve the NAT problem unless you are behind a single simple consumer router. In many ways, it makes it worse since it tries to map out the entire route. Sip proxies would solve the NAT problem if they were easier for non SIP gurus to configure. (And the embedded PBX solutions are generally that easy.)

I read a bit about Jingle. It still uses RTP for the actual voice/video, so it has the exact same NAT problems as SIP (that STUN does not solve except in very simple cases). The only open protocol (other than IPv6) I am aware of that completely addresses NAT is IAX - where SIP and RTP are encapsulated in a single UDP port.

Actually, IAX2 (the "official" name of the standard) is not SIP, nor is it RTP. It has it's own RFC 5456. It's both signaling and media combined in the same packet stream, and it actually is quite nice for client-to-client systems. However, it does NOT solve the NAT problem. There still needs to be an intermediate system in the middle if both ends are behind a NAT.

Note that Skype has the same issue; there is no magic bullet. But Skype will "leech" off of the bandwidth of hosts that have public IP addresses, using unsuspecting client "A" as a relay point for clients "B" and "C" who wish to talk. That's how it scales. IAX2 and SIP don't have the concept in the protocol that talks about how endpoints find willing media relays, though if someone wrote a suitably clever wrapper at a higher layer they could make such a client. But that's complex, and programmers of lower-layer stuff like IAX2 and SIP tend to run away screaming when the discussion moves to larger-scale and higher-level issues like that. "Leave that to a company to figure out" is the reply.

Thus, Skype is the only one at the table, and they decided (wisely) to ignore ALL the standards when building their system.

JT

"However, it does NOT solve the NAT problem. There still needs to be an intermediate system in the middle if both ends are behind a NAT."

Sure, but the intermediary doesn't need to relay the RTP packets. Once both ends know each others public IP and port, they both send UDP packets to each other, and both NAT firewalls open up the (single) UDP port. Some SIP clients are clever enough to do this for each RTP channel (using the same port for both incoming and outgoing multimedia data). But keeping everything in one UDP port makes things much simpler.

Take a look at Jingle Nodes; it's a relaying protocol which allows clients to act as relays for their contacts (only), if they wish to, as well as supporting public media relays as well.

XMPP does not, of course, need management of signalling relays, since it already has the existing XMPP server federation to act, in effect, as a giant signalling relay. And Jingle Nodes allows this existing framework to be used for finding media relaying services, offered by your server or your contacts.

Really, media relay discovery isn't that hard a problem to solve if you've already got contacts, servers, and service discovery.

I've had good luck with Ekiga, although you do have to actually pay a carrier to talk to people. Skype on Linux is utterly useless - it's way behind the Windows client on functionality and often just doesn't work.

<em><strong>There's really no free lunch in telecommunications.</strong></em> It's a core enterprise IT capability and should be purchased / leased using the same business processes one would use to acquire databases, ERP systems, content management systems or vehicles. Competitive procurement is an idea whose time has come and has stood the test of time.

No one mentioned sipXecs ?- it is an open source UC alternative that should be looked at for SIP and XMPP based communications, it allows native federation with systems such as Google Talk, CallManager presence & IM, and many Jabber based systems.
easy to download and use, plug and play....http://www.sipfoundry.org/home

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.