Cross-Platform VoIP Software? 205
feilkin writes "With the release of Skype's Linux client, I'm wondering about alternatives. Namely, cross-platform solutions for voice communication. I've got friends who are using Windows, Linux and OSX, and I'm hoping that there is a way to communicate with all of them. I myself am using Linux, and I haven't been able to find any solutions that seem fitting to my situation completely. Does anyone have a solution that'll be useful on all three platforms, or solutions that may be coming in the near future?"
SIP (Score:5, Informative)
pulver's FWD is fantastic (Score:5, Informative)
FWD (Score:3, Informative)
I've got friends on it using windows and linux (I personally use both, and have clients installed on both). I'm pretty sure they've got osX clients aswell.
SIP solutions (Score:5, Informative)
OpenH323 (Score:5, Informative)
Non-OSS sip for windows and macosx (Score:2, Informative)
SpeakFreely used to be an option... (Score:5, Informative)
At this point, all the tools needed to create an Open Source cross-platform VoIP system are easily available. The Speex [xiph.org] codec is specifically designed for low-bit-rate voice, is BSD licensed, and is implemented in both C and Java. It would not be hard to take this codec, throw in some good sound libraries and some crypto libraries (OpenSSL perhaps) and roll up a VoIP client. In fact there is a Speex implementation for Java, so you could write one in Java, and yes, Java really is "write once run anywhere" these days. Someday when I have more time I might do this. As a Java applet it would be great because there would be nothing to install.
Re:FWD (Score:3, Informative)
SIP (Score:4, Informative)
Re:err...Yes Skype (Score:5, Informative)
Open Standards (Score:5, Informative)
SIP and h.323. There are lots of clients out there for both of them.
There should be a checkbox next to the "ask slashdot" submission box that says "did you use Google first?"
Re:SpeakFreely used to be an option... (Score:5, Informative)
Re:Standards? (Score:3, Informative)
Re:err... (Score:3, Informative)
Ventrilo (Score:2, Informative)
Has Win32, Mac and Linux clients.
It is client/server, so you'll need a server, but you can get 8 users (I think) on the regular server. It is relatively bandwidth-friendly and awesome quality.
Probably a bit harder for computer illiterates to use but its very cool software.
Re:err... (Score:2, Informative)
h323, sip (Score:2, Informative)
I don't know much about sip, but everyone tells me "stop using h323, use sip". Seems to be better, but never change a running system.
h323 is only for VoIP, not for calling real phones - unless you have an gateway to the "real" world.
There are many h323 programs available, like netmeeting (really hardcore connectivity problems through firewalls, better use...), openphone (openh323/windows), gnomemeeting(openh323/linux) and so forth. Normally, all h323-compatible apps should be able to communicate. You can use many different audio codecs, depending on your bandwith and data rate quality. There's even the (in)famoues GSM codec that's used in european cellphones, sounds quite good for 1.6k/s+overhead.
Re:SIP (Score:5, Informative)
A number of years ago, the telecom providers got together and tried to do VoIP. They came up with H.323, which was a terrible mess and near impossible to do anything with. To top that off, you have to pay for access to the spec (I'm only pretty sure about this, please correct me if I'm wrong) So VoIP didn't go anywhere for a while.
Then the IP folks (the people who designed the internet protocols like IP, TCP, UDP, etc) came together and designed SIP. The entire protocol is described in a mere 150 page RFC [faqs.org]. Anyone who's implemented a standardized protocol from a spec knows what a godsend a short spec is.
In short, SIP is a protocol designed by the Internet folks for the Internet. It's layered on RTP [faqs.org], so the audio quality degrades gracefully with the link quality. You can operate it point-to-point by simply running two clients on two machines and pointing one at the other's IP address. Or, if you want an easy to remember URL, you can sign up for a free account at places like fwd.pulver.net. You'll then be accessible as sip:username@fwd.pulver.net.
Google for "SIP softphones" and you'll find quit a few clients. The big ones on linux are kphone [wirlab.net] and linphone [linphone.org]. Shtoom [divmod.org] is making some headway also, and runs on linux, windows, and os x.
Skype decided they don't like either H.323 or SIP, went off and designed their own proprietary protocol, and is keeping it secret from everyone else.
complete solution! (Score:4, Informative)
h.323 for all (Score:2, Informative)
Gnomemeeting for Linux [gnomemeeting.org]
OphoneX for OS X [sourceforge.net]
Netmeeting for Windows [microsoft.com]
Re:pulver's FWD is fantastic (Score:4, Informative)
Asterisk (Score:5, Informative)
This thing is a VoIP BEAST. It's an open source PBX which runs on Linux. This will solve your problems by connecting all of these incompatible VoIP clients, making them all seem like virtual telephones, each with their own extensions. (This is good, if you don't mind them using your bandwidth when they bounce off of your Asterisk server to communicate with each-other.)
"PBX" seems scary -- it's the same kind of system large businesses use to manage tons of phone lines, both inside their company and connecting to the outside world.
For the needs of people like you and I, don't think of it in terms of "a solution used by people with lots of phones" -- think of it in terms of the kinds of technology it uses and can connect with.
"Physical layer" stuff: with dedicated hardware it can talk to existing phones and existing phone lines. There's even a PCI card that can communicate with four T1 lines, for nearly 100 phone lines out to the telephone company. It can also do VoIP using standard interfaces like SIP, using its own unique (but open-source, not proprietary at all) interface called IAX, with existing programs like Netmeeting or MS Messenger, or with any number of Linux programs. (There's even an IAX client for my Zaurus PDA. That's not all that practical for receiving calls, but I have successfully placed phone calls with that client, over 802.11b.)
Logical stuff: each of these connections to the outside world is given a context, and you can do things with those contexts. A connection to your outside phone line will be used by unknown callers, so its context shouldn't have access to features that cost money. A connection to an inside phone is "trusted", so it should be given access to these features.
The system has something like a "dialplan", which is a rather flexible set of scripts you use to handle calls. There's a lot of room for creativity here -- you can make your system do anything you want with any call.
This is so flexible because you form your dialplan from a bunch of references to "applications", either built-in or external. Some are very simple: play this wav file, transfer to this extension, go to this voicemail box, etc; some are more complex, such as "shell out to this executable CGI-style and do whatever that executable tells you".
Asterisk also comes with a bunch of audio samples recorded by a "professional PBX voice", and many of them are saying some rather funny things, only useful for a home user. "All representatives of the household are currently assisting other telemarketers. Please hold, and you call will be answered in the order it was received."
Asterisk can email you your voicemail messages as wav files. This is a KILLER feature. But you weren't asking about voicemail, you were asking about VoIP.
Pros: VoIP BEAST. Take all your friends with VoIP clients, give them signins and extensions and voicemail, give them conference capabilities, etc. (Then they all use your bandwidth.)
Cons: Complexity. Even if all you want is a simple call routing tool to make incompatible VoIP systems talk to each other, you have to learn the entire system to make it work. This is a typical Linux problem: you have to read tons of documentation / visit forums / discuss with others to figure it out, but because it uses "real world" concepts and is designed intelligently, once you're finished you have spent 30% of your time learning the quirks of a single software package you could care less about, and 70% of your time learning about how the subject works, gaining knowledge about that field that will follow you to any other program.
(That's definitely true here: Since playing with Asterisk I've talked with professional telecom guys, and found what few terms and concepts I've learned from Asterisk definitely overlap with their "real world" stuff.)
Weird system service requirements. Some software features rely on a very high-resolution system timer, and (allegedly) can't get t
shtoom (Score:5, Informative)
It also includes 'doug', an application server for writing voice apps. There's a simple voicemail and simple conference server implemented in doug.
It's pretty rough - it's certainly not something you'd give to your mother to use, but hey, it's free software.
It's also entirely in Python.
At the moment, the best bet is to use the svn trunk.
URLs:
Software: http://shtoom.divmod.org/
PyCon paper (also possibly useful for an overview of VoIP): http://www.interlink.com.au/anthony/tech/talks/Py
[1] Native Mac support will be finished Soon, I have a mac being shipped to me.
Re:shtoom (Score:2, Informative)
I installed the libraries, installed the client, ran it, typed in a sip address, hit 'call' and *volla* I was talking to some dude from alabama (I'm in
Cred to anthony for writing it.
Shtoom - Cross platform VoIP in Python (Score:1, Informative)
shtoom - the end-user phone
shtam - a simple answering machine/voicemail application
shmessage - an announcement server
Re:Ventrilo (Score:3, Informative)
Unfortunately, the don't have Mac or Linux clients. Or, at least they're not available. Both are listed as "In Development" on their download page.
Re:SIP (Score:4, Informative)
The actual phone conversations run over RTP whether you're using SIP or H.323. It's how the call is set up that differs.
SIP uses set-up mechanism that works over HTTP, arranging the caller, receiver and codecs etc. Because of this it is simpler than H.323, which uses loads of other protocols that run over a mix of UDP and TCP, such as H.225 (call setup/RAS), H.245 (call management) and a few more I should probably know but have forgotten. H.323 needs a separate "gatekeeper" to control connections whereas a SIP client can use the DNS to find it's destination, addresses in SIP look similar to email addresses but may include a port number aswell.
Re:SIP (Score:3, Informative)
Bzzt!
SIP (aka RFC3261 [ietf.org] et al.) uses SIP to setup calls. The syntax of SIP is clearly inspired by HTTP, but HTTP it ain't.
Location of SIP services is handled through DNS operations as described in RFC 3263 -- Locating SIP Servers [ietf.org].
Why, oh why we don't locate HTTP services using SRV or NAPTR records is really a sad question -- virtual hosting would work so much better.
Most everything else you mention is fairly accurate. There are excellent SIP resources online at Sip Forum [sipforum.com].
The NAT problem is over-rated. Service providers routinely solve it with an SBC [google.com] or special ATA devices.
Better yet (Score:3, Informative)
It is basically a phone with an ethernet port and SIP built in. Not bad.
RFC 2543 is obsolete, see RFC 3261 (Score:5, Informative)
NAT is problem for residential gateways (Score:4, Informative)
Sure, SIP can use TCP as a transport, so a client can punch a signaling connection out through a residential NAT/gateway, but a SIP client still needs to advertise an address and port to receive RTP on. He can't very well advertise his NATed address if he's connecting to a client outside of his NAT.
STUN - RFC 3489 - (http://www.ietf.org/rfc/rfc3489.txt) partially addressed this problem, by allowing an application to discover its public address and port mappings.
TURN (http://www1.ietf.org/internet-drafts/draft-rosen
ICE (http://www.ietf.org/internet-drafts/draft-ietf-m
And it's backwards compatible.
It should also be noted that ICE is independent of SIP, and could also be applied by H.323 clients, or RTSP streaming client/server for that matter.
Check out Vovida.org and VOCAL (Score:2, Informative)
Teamspeak2 (Score:2, Informative)
Oh-Phone (Score:2, Informative)
Go with a hardware SIP phone (Score:5, Informative)
As for phone clients
My honest recommendation would be go for something like the Grandstream, which does everything an "ordinary" phone should do and, being hardware is truly cross-platform. But note, it doesn't have any integral switch so you will take up an extra jack on your ADSL router.
Re:SIP (Score:3, Informative)
Re:Better yet (Score:3, Informative)
They're pretty horrible but a good intro to VOIP if you don't want to spend much. You could get an SPA2000 for a little more and be able to plug your DECT phone directly into it - wireless VOIP on a budget.
Asterisk is king (Score:2, Informative)
The IAX protocol, which is a Asterisk-specific VoIP protocol, is great behind my IPCop box since it effortlessly works with NAT, requiring not a STUN server or any other kind of help. I've bought pre-paid VoicePulse Connect service for long distance calls to PSTN, and since I don't do much long distance its really a cost saver since I don't have to pay SBC all that money. For local calls, I have a clone-Wildcard PCI card I found off Slashdot. This isn't really a requirement, as you can get local numbers in most areas. Just not mine.
Bottom line: If you want to get serious about VoIP, start tinkering with Asterisk. Its going to be the Apache of VoIP. No doubt.