Slashdot Mirror
Cross-Platform VoIP Software?
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?"
http://www.sipforum.org/
I have no problem with your religion until you decide it's reason to deprive others of the truth.
http://www.skype.com
------- ?
fwd.pulver.com it has clients on all platforms. the other one is called asterisk
http://www.freeworldialup.com/
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.
I know nikotel works great on windows and macOS and as it is SIP compliant it works with linphone and kphone on linux.
download and burn linux with one click on windows
OpenH323 is available on all 3 platforms and has very good voice quality. It can do video as well. Setup is not always trivial: it needs lots of open ports, udp and tcp. The license is MPL.
At this point, all the tools needed to create an Open Source cross-platform VoIP system are easily available. The Speex 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.
Does anyone have a solution that'll be useful on all three platforms?
Son, I have a solution! Pick up the phone and call your friends!
You're looking for a standard protocol that can be used across all platforms, and that protocol is SIP. I've used several VOIP products that have SIP support and currently am using a Grandstream Budget Tone 100 VOIP phone ($65) to do my calling and can contact anyone on any platform that can support SIP.
I've just tested the Linux version of Skype here -Local box to box - Linux to windows - 2 accounts etc..works as advertised. But just from a technical point of view being an old coder myself, i'd like to know how they minimize the lag.. Dam this thing works better than my cell from a lag-latency point of view.
*--- Sometimes a majority only means that all the fools are on the same side. ---*
There are two main standards in use for VOIP:
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?"
UT2K4 has built in VoIP support and is available for Windows, Linux (32 and 64 bit), and Mac! "No, sir, we're not wasting company time, we're _collaborating_! We're enhancing shareholder value! It's a whole new paradigm!"
SIP is a VoIP standard used by a lot of company doing VoIP comercial services like vonage or cisco.
For 29.99 USD a month, Vonage is the way to go.
No fscking around with codecs.
No gcc bullshit.
No patching, only to have an OS upgrade break your app.
Pay for it, be done with it, move on. What's your life worth? Time = money.
I want to delete my account but Slashdot doesn't allow it.
Sure, you can't talk to people who only have POTS.
Sure, its designed to be used with online games.
But really, its just IRC with voice. I talk to people in Australia with it all the time, for free. You can turn the bitrate down and even talk to people with dial-up. I usually just use gaim to tell someone "hey, join the teamspeak server, let's talk".
Also, this way I don't have to remember phone numbers.
The GeekNights podcast is going strong. Listen!
For a complete VoIP Linux solution, check out Asterisk.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
www.asterisk.org
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
Shameless self-promotion - check out the shtoom program. It's cross platform (although the Mac support is incomplete, it in theory works, thanks to portaudio[1]), it has user interfaces for command line, Tk, Gtk, Qt, and wxWindows. Audio support is via PortAudio and OSS. It handles most NATs correctly (using STUN).
C on2004/
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.
The SIP RFC you linked to is obsoleted by RFC 3261
The NAT problem is definitely NOT overrated for residential gateways. There is no SBC in this case.
b erg-midcom-turn-04.txt) addressed the problem, but in an inelegant manner, by routing all RTP through a public server.
m usic-ice-01.txt) describes a method of using STUN and/or TURN to discover, describe, and prioritize many potential addresses. Using ICE, two SIP clients can choose the best possible route for RTP, through several NATs that might separate them.
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.
On June 16, 2004, there was an internal demonstration at Skype of the alpha version of Skype for Mac.The alpha version worked well and the development team is working towards a beta launch of Skype for Mac in about 2-3 months. The other major OS that Skype doesn't support is Windows 98, and there aren't official plans for that as of yet.
- Allen Pike
Altering time, one time at a time.
Ever since my boss got friendly with the Asterisk developers, my company's internal telephone network is now almost entirely VOIP. We have a server running Asterisk, with a Zaptel line card (needed a 3V3, 6MHz, 32-bit expansion slot; something you apparently only find on high-end mobo's, as most of the low-cost ones are 33MHz and/or 5V) plugged into an E1 line giving 30 ISDN lines. But you only need this to connect to POTS phones -- connecting to other VOIP phones is just done over the internet. The Asterisk machine also currently runs our intranet, though I'm ordering a new server for all the non-telephonical functions as something keeps crashing (not often enough to be serious, but we need to narrow it down).
..... we use dedicated hardware telephones. The Grandstream BudgeTone 101 was the first we evaluated, be aware that this comes with a Continental-style mains adaptor so you may need to get a new power pack (regulated 5 volts 400mA DC + --o)-- - polarity). This works lovely as a SIP telephone but doesn't as standard allow for a headset, which we kind of need in a call centre. The handset does use a standard RJ01 connector, but there seemed no easy way to deal with the receiver switch. We also evaluated every softphone we could get our hands on. In general they seem to be a bitch to get to compile; I had the best result with Linphone, it wasn't as polished as KPhone but it seemed to crash less often; and got absolutely gnowhere with Gnophone. Bear in mind also that a telephone headset will reveal the limitations of the sound chipsets on modern mobo's: you will require a real SoundBlaster-compatiable if you want to be able to understand what anybody is saying. I am running Debian Sid, my boss is running some perversion of Mandrake with a load of stuff from Cooker, and all our workstations run Mandrake 9.2 (hackerish systems are fine for us hackers, but it's more important to have Stuff That Just Works for the masses). We also got a softphone client from Zultys, called LIPZ; which looked stunning but was problematic in practice. It seems to bogart memory and CPU cycles. And when I came to do some hacking on it, I found the real kicker: it doesn't include the source code, so who knows what the hell it's really doing? In the end, we wound up using Zultys ZIP4X4 hardware SIP telephones. These are very expensive for "just" a telephone, but they are stuffed with features, all known codecs, 4 virtual lines, even an integral 5 port (one for the phone, four brought out on RJ45 jacks) 100Mb/s switch, and they are hardware -- my favourite programming language is still 63% tin, 37% lead.
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.
Je fume. Tu fumes. Nous fûmes!