Slashdot Mirror
Cross-Platform Internet Telephony?
the . Silicon . Dragon writes: "The company I work for is creating a product that we hope to launch on Linux. One of the key features of our product is Internet Telephony where a user can not only call other users on the Internet, but also make and receive calls from standard telephones. We've investigated a number of possible solutions, but they all have shortcomings. The most sour part of the situation is we may have to move our launch platform to Windows if we cannot find an acceptable Internet telephony solution. It'd be highly disagreeable with myself and several others in the company as well if we have to do this, but we can't drop a key product feature and we don't have the time or the resources to develop the technology in-house. Suggestions for Java (preferrably) or C/C++ solutions, and/or references to companies that provide said technology would be extremely helpful." The 'key feature' in question is interface customization. You can find out more in the article.
"It is an absolute MUST that we be able to customize the interface of any such client application. Second, it MUST be able to run on Linux and Windows with minimal pain (the product is coded in Java). Lastly, the quality MUST be fairly high. So far, solutions like HearMe and OpenH323 are either incomplete, lack quality, are not cross platform, and / or do not allow us to create our own interface."
http://www.speakfreely.org/
Hey, Ask Slashdot editors: Could we get a slightly higher quality of question and less repetition (we've had the "internet camera" question at least twice).
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
I know this may cause thousands of readers to pump up their blood pressure, but if it's a commercial company, then it will naturally target its products on windows (let's face it, if it's a product that needs to make money, windows would be more sensible, not because of the platform's attractiveness, but because that's where the most users are. And this sounds like a home consumer type of product as well.) I can understand it if you want to target BOTH windows and linux, but from your description, it looks like you're sour about moving from exclusively linux to exclusively windows. Why not both?
After all, if it's written in java, that would be one of the key advantages. btw, did you look on computer telephony magazine?
w/m
Don't worry, I got it.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
The only thing missing in this post is the "funny" flag. I couldn't help laughing!
Voice over IP has been a hot subject for quite a while now, but till now we've never seen it being realised on big scale. First I think it has been marketised too much. Voice over ip is not rocket science. For me, it doesn't say more than 'telnet over ip'. Classic telephony calls are practicaly 100% reliable. TCP/IP connections are too unexpectuous: theres a big risk on delays, that are not important for data, but are so for voice. With TCP, you're sure your packets arrives, but it is too slow for voice packets. UDP hasn't this checking, is fast enough, but you are not sure the packets are delivered. How many times we like to see realaudio clips, but that we can't get a connection. Internet telephony is super for applications like netmeeting etc, but when somebody with a real telephone calls another , he expects that his call arrives, not that it is in a jam. People are used to this. So, in my opinion their will not be evolution to internet telephony as long their is no protocol redesign.
I have been creating a bunch of 'telephony related' tools for Linux for internal use. IMHO - VERY few programmers understand the difference in mentality needed for telephone type applications vs. 'regular' data oriented applications. There are essentially NO telephony oriented tools available. I AM interested in making a few so we can test our test equipment products for proper operation prior to general release. Perhaps some sort of telephony group makes sense. I AM interested. john harrison concord nh jmh@nei.mv.com www.neinnov.com
Sir, you are even a moron, a poor Troll, or both. Funnily enough, my money is on both. Oh, and you're also a dolt. Dolt.
.the anti-troll
Java has a Telephony API, have you looked at that yet. I'm not sure if it is exactly what you want but it is a place to start. Here's a link: http://java.sun.com/products/jtapi/
http://www.linuxtelephony.com/
is a good place to start.
.
What the hell are you blathering on about? Java can be fast enough to run a math intensive problem such as a/d conversion etc.
.the anti-troll
As for your deluded idea that "all Linux applications have to be written in C or C++" is laughable. We the hell shouldn't you write in assembler and distribute a binary instead of source? Why not hand optimise a C or C++ compiled program yourself? If you want it to be multi-platform, write it in assembler for each platform you want it to run on.
Your last paragraph is a stupid, obvious Troll attempt at flame-bait. I won't even bother answering it. Just go home, little boy.
I'm surprised with so many people having little webcams and dsl/cable, that videoconferencing doesn't have its own household names.
The only program I used with someone to get a semi-successful videoconf was Intel Video Phone. I looked just fine to him, but he looked like a 2K/sec RealVideo clip, and we could never figure out why. I couldn't get Cusemee to work(some cryptic errror message), and MS's videoconferencing software(netmeeting 3) was a joke.
Sadly, none of these packages let me seek someone else out with the sw just to try the damned thing. So my intel create & share cameera has been demoted to "webcam" and nothing more
If you think about it, VoIP is more efficient than your "honest" + "proper voice line".
CELP == Code Excited Linear Predication
I believe it's been around for a while (1970's?).
Tim --
Just reverse engineer a Linux client. I've had no problems with it in the recent past. Oh BTW anybody know of a Linux client? thanks all
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Check out dynamicsoft for a SIP based IP-Telephony solution done in primarilly in Java but with some C++ with the user agent.
i work for a company called dialogic, and we have single/dual/quad span t-1 and e-1 VoIP solutions for for linux. Granted the price tag may be a bit steep, but the sdk is quite flexible and powerful. Check out http://www.dialogic.com/
so much beer, so little time
www.brooktrout.com these guys have just ported many of their IP telephony products to Linux. http://www.brooktrout.com/pages/news/press/2000/06 27linuxnewnetwork.html jim
I am not trying to be mean, but this is a horrible question. What do you mean by develop "your own technology"? Almost any programming project requires a certain amount of innovation (if its to mean anything, and be sellable by a company).
<p>
Secondly, like a previous "ask slashdot", you are confusing the method with the language. This is almost completely dependent on what the employees in your company. The question of whether to use Java is not so much a question of language, but whether you need it to work across platforms. However, keep in mind Java tends to be slow, and usually not such a great thing for realtime involving a lot of data.
<p>
If your company decides to use linux, there are many tools available for sound transfer. There are at least 2 or 3 sounds projects I know of. TCP/IP is almost free using any UN*X clone, and that sounds like the majority of your project.
Quicknet has a low - cost 1 port card that will do the trick with Linux and Windows drivers:
http://www.quicknet.com
Also check out Pika for 4 port cards with traditional analogue and VoIP capabilities with Windows and Linux drivers:
http://www.pikatech.com
Aslo check out the Bayonne project. Linux based Open Source telephony system with interfaces to Quicknet, Pika, and other cards:
http://bayonne.sourceforge.net/
Skins and the like are evil. If you are writing the application, write a good interface and leave it at that.
It seems like the ability to change the interface should not be considered a vital part of an Internet telephony application.
Just the opinion of a user who would prefer to let experts design user interfaces so he can use them and be amazed at how intuitive and easy to use they are.
Bolie IV
If you are aiming to make this work over the next few years then you need to look at broadband and IPv6. Current IPv4 and lowbandwith connections are worse than a current phone service. With the advent of IPv6 on the next generation of mobile phones the question also has to be asked...
Why bother ? If a mobile phone has perfect voice and a 2Mbps peak bandwith, why use a bulky PC ?
(NB this applies to Europe, Africa, Asia and Australia, its probably not appropriate in the wireless backwaters of the world:-)
An Eye for an Eye will make the whole world blind - Gandhi
That link is a porn site, and a bad one at that. .the anti troll
This is the same Dialogic that had to be dragged, kicking and screaming, into supporting Linux. I hassled them (literally) for years, but they gave the usual excuses that nobody used Linux, that it was unreliable, and so on. I told them that there would come a day where lack of Linux support would make them look bad. After that day came, they announced (but didn't ship for quite some time) Linux support.
By the way, beware dealing with Dialogic Tech Support. You may get to talk to a person, but that person probably won't understand your problem. I've got a long laundry list of occasions where Dialogic left me high and dry.
Dialpad.com uses a Java applet to connect to phone systems and to other computers.
I never pay for long distance anymore. AT&T sure tried to convince me that Dialpad.com was crap. I explained that the amount I save in long distance makes up for my DSL line payments and that DSL and Dialpad worked just fine together.
Setting his threshold to 5, Sparky eliminated most of the trolls on /.
Actually, with a good compression codec (which are quite common), VoIP can take up less bandwidth than a regular analog call. For instance, with CELP compression it's possible to have a full-duplex communication channel in 9600bps (600Bps * 8b/B * 2directions) + protocol overhead (IP + UDP header lengths anyone?) so on a typical 33600bps connection you could likely squeeze 3 simultaneous conversations. IMHO this is why there was a big push in the wireless telco industry to move to digital (what do they really care about call security?). You will see Voice over IP a lot more in the next few years, simply because it's cheaper to implement than traditional, circuit-switched telephony. It's not a bad thing, really, because the telcos are going to have to make it work 100% of the time. That's the #1 concern. People have been getting dialtones all across this continent for 50 years now. It's simply not acceptable that suddenly you only get 9 out of 10 dialtones. It's got to be 100% or it won't fly.
Telecommunications companies already provide voice communications and data communications. Each one is priced according to its impact to the telco's network and other costs. By using a data link to transfer voice you are cheating the telco of their deserved revenue. It is just like buying a CD recorder and copying commercial software: just because you can do it so easily does not mean it is legal or moral.
Actually, there is an entire ETSI European Telecomunications Standards Institute) effort devoted to this. It's called TIPHON, and it is devoted to the merging of data and telephony networks. One of it's working groups (WG5) is devoted exclusively to looking at Quality of Service of voice over IP. I sit on this group, and I can tell you that while there are a lot of problems, there are also a lot of people trying to solve them. All the major telco manufacturers and many operators are represented, because the advantages of providing a VoIP network are huge. I also believe that one of the long term goals of 3gpp is to provide mobile IP and VoIP on UMTS mobile terminals. Which is kind of cool...
With good sound quality and high reliability at last I could dial my ISP to access the net!
G.728 = 16 kbps duplex
G.729 = 8 kbps duplex
The key thing to understand about ITU voice codecs is that they are very very carefully designed to 1) have predictable RAM requirements, 2) have predictable CPU requirements and 3) work well when concatenated with other codecs.
#1 and #2 are clear. If you have known max CPU and RAM requirements, then you can design your codec board with a given processor and memory and be assured that at the end, the software will have enough hardware to do the algorithm. Remember that these codec typically exist in the embedded world where margins are thin and resources must be planned.
#3 is different. What if you are on a cell phone (algorithm #1), with a satellite backhaul from the remote city you're in into the telco headend (algorithm #2, perhaps ADPCM), then through a VoIP backhaul (algorithm #3)? Nearly guaranteed to sound like crap -- lots of swirly audio artifacts, even though going through just one of those algorithms sounds just fine. G.728 and G.729 are designed to work well concatenated with themselves and other codecs while using up reasonable CPU and RAM resources.
As chips follow Moore's law, new algorithms will come out that use more resources to squeeze the signal further, perhaps to 4 kbps and lower.
One simple rule for its versus it's
No you cannot.
;-(
A typical 33.6 has 130ms latency and is half duplex. Telephony over it sucks. But over a 64k ISDN or similar it gets to be really interesting.
Problem here is that the bandwidth is getting cheap and interest in compressed codecs in service providers is decreasing. So providers are getting less and less interested in incoming IP calls. They look mostly towards telco termination and even exchanges.
Also in order to use end user IP telephony especially at the office level you need good QoS on the endpoints so a download does not blow away the voice. This is something that is not common in most end user/small office setups.
So end-user VOIP and compressed codecs are actually a subject of interest for very well maintained office to office VPNs with QoS which are rare. In the other cases they are usually a cause for yet another disappointment
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
First off, if you're looking for a way to make your interface customizable at runtime, one easy one is using libglade. It's a library which builds interfaces at runtime based on XML files output from GLADE, a GUI builder for GTK. Want a new interface? You don't need to recompile, just swap out the XML file. And if you want larger changes to the widgets themselves, well, that's what GTK themes are for...
As for the unmet telephony needs of your product, could you be a bit more specific? Hardware-wise, I've seen some Darned Good Stuff put out by Quicknet, though if your pricetag makes integrating their hardware an unworkable solution, there are still other possibilities available. For instance, at least one telephony project (Asterisk) has been working on having software phone integration through some supported voicemodem hardware (though the latency and whatnot still doesn't compare to having proper hardware compression, ala Quicknet). This was rather a while ago that I was on their mailing list, and while their work is far from a finished product (well, was last time I looked), you still should find it useful.
Thats the way IP based comms are going to be set up. Bet on it. H.323 was designed to communicate to SS7 over an ISDN line - its a telco/wireline oriented protocol stack - lots of stuff you don't need in there. SIP is cleaner and better - and there's already an open SIP IP-masq-proxy for Linux at www.sip-happens.com from a 3Com engineer.
Also, if you want to ride the internet, try making QoS a value-add item - you can give the phone away for free (Opens Source that puppy!), and make money by providing a good backbone with colocation in major cities to drop off the calls to the PSTN. And if you can find one, get one that can route the voice over IP packets for you. A place to start might be Qwest (the most well known), Global Crossings (Lots of fiber world wide), or Level 3 (the only end-to-end IP global fiber network).
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo! http://goo.gl/J9bkO
Why didn't you tell us what solutions you looked at, and why they were not acceptable??? This question as asked is grossly inconsiderate, guaranteed to waste your time and ours with useless replies.
Actually interest in Codecs isnt dropping - its just movingover to the bandwidth limited world of wireless. IP (IPv6?) is going to be the way the 3G wireless mobile "phones" operate, and for now the digital network (CDMA TDMA CPDP and GSM) are pretty much limited to 14.4K - that means a good data compression codec is needed (g711 or g729)
And there is a lot of talk about bettering those codecs which will use even less of the available spectrum and bandwidth. This allows even more data to flow to the mobile device (go to Japan nad check out DoCoMo and iMode from NTT to see what a "wireless data culture" is starting to look like).
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo! http://goo.gl/J9bkO
The only VoIP protocol that a majority of firewalls supports is Netmeeting.
;)
There is a push (albeit small) for more firewalls to support h.323 in general. Unfortunately, h.323 is like FTP in that it opens auxiliary connections to random ports so it takes alot of processing per connection. And to top it off, the control channel uses ASN.1 like SNMP.
ASN.1 fields are variable length, ie:
Byte 1 : Variable type (integer, string..)
Byte 2 : Length of variable -- this is also a variable length field.
Byte 3 : The actual variable Data.
Byte 4 : The next variable type.
So you esentially have at least one branch statement per byte in a packet. And the variables of importance to firewalls may be buried several deep. Lots 'o processing.
Don't ask me how you plan to connect to someones internet phone behind a firewall. VoIP in a semisecure environment is like a one way phone. You can call people but they can't call back. Ideal if you ask me
www.ini.cmu.edu/eclub is an all Java suite of telephony stuff developed by students at CMU as a masters thesis in the Information Networking Institute. Take a look.
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
Voice over IP isn't something new. Been around since at least mid-1998. There's a reason - it's not good enough. I speak from experience. I was responsible for the deployment of a national VoIP network using a strictly hardware based solution. And it sucked. Flat out sucked. Going international to a single POP across the Atlantic was even worse, even with a PVC on PanAmSat.
Flat out, TCP is too unpredictable, and not enough solutions are carrier class. There are very stringent requirements for carrier-class quality. And TCP/IP is NOT carrier class. Oh, sure, you can claim it just by slapping on a -48V DC powersupply, but it's not carrier class till you can give *proven* 99.999% uptime, AKA Five-By-Nine(s). There is absolutely *no* VoIP solution that can do this.
Furthermore, MANY VoIP routing solutions are entirely dependent on the H.323 or H.323v2 pseudo-standard, which uses UDP - an inherently unreliable transport - to transmit and recieve call routing information on a per-system per-port level. H.323v2 is also bandwidth intensive. And I have yet to see a system that can interconnect H.323v2 with SS7, which is the absolute standard for all telephone call routing, as defined by Telcordia/BellCore. The Lucent 5ESS runs SS7 for routing, I shouldn't need to say any more than that. This may have changed in the time that I have been out of VoIP, but I doubt it.
In order to bring VoIP to carrier quality, basically, a new routable Layer 3 protocol with inherently reliable transports would have to be created, and all compression schemes would likely have to be eliminated. The compression inherently damages quality, well below acceptable levels for anything useful. Testing a 33.6k modem over a VoIP routed line resulted in 4800 connects at best. The compression causes gaps in conversation, and only increases with latency.
As latency increases, call route reliability decreases exponentially, due to H.323/H.323v2 utilizing UDP transport. Packets are dropped and not retransmitted, resulting in incomplete or lost call route instructions. Suddenly that call to Grandma in Houston, TX from your house in Boston, MA, can't be completed. And bandwidth is choked quickly. Two PRIs worth of circuits used for incoming/terminating VoIP calls will eat a full 6Mbit pipe quickly.
Cisco claims or claimed that the AS5300 equipped with Voice over IP blades had 5:1 audio compression with minimal quality loss. While people were understandable, gaps in the conversation were also very audible, from dropped packets or other inevitable network issues. At a supposedly 5:1 compression ratio for the data transmission, I saw a single call eat nearly half a megabit. A PRI is basically 24 voice channels versus 24 data channels. In effect, a T1's worth of voice channels, using digital format versus standard analog, allowing 24 channels to be carried over four pair copper.
To claim VoIP as carrier class is similar to claiming that a PC at the store is carrier class. Or that just because a system has a -48V DC powersupply, it is carrier class. As I said above - carrier class is defined by reliability, not just feature set. I honestly don't know whether or not any of Cisco's equipment qualifies as carrier class - for certain, in my experience, I would be very uneasy about slapping that label on their Voice over IP equipment.
Furthermore, as everyone gets 'hip' to VoIP, the market is becoming flooded with companies. And much like has happened with so-called 'e-tailers,' there's going to be a purging. Those with the real brains, the right technology, and get in at the right time might make it. Those that don't, don't. IMHO, the time to get in has already passed. It takes time to build a massive data network to begin with, much less research all the equipment available in order to find a reasonably reliable combination.
The PC solutions are no better. The quality is horrific at best, after seeing probably close to 90 different 'solutions' that were anything BUT. They are unreliable - the hardware-based solutions even moreso - and offer very very little quality, much less return on investment potential. I spent a lot of time at a PC trying to get one particular card to work and watched as the card itself gave up the ghost and shorted out itself, due to extremely poor manufacturing quality.
My recommendation? Abandon the idea and cut your losses while you're still ahead. There are other options out there with better profit potential that aren't reliant on a killer IPO performance. Maybe there'll be a maturing of VoIP technologies - maybe even a standardization (HA! Yeah RIGHT!) in the coming years, but now is not the time or place to try it.
=RISCy Business
your company here.
shelby != ford
Seriously.
---
I am the dot in slashdot.org
I'm sorry, but I'm a little tired of people crying that they can't find someone else' "open free software" to add to their planned multi-million dollar product. You are a developer, so please go develop it yourself or hire someone or contract some company to do it. I prefer to support those who have the guts to bring a product to being with their own sweat. Technology does not progress when you keep riding on the backs of others. If you can't do it, please find something else to do. I know, flames abound, but I am a developer, and I choose to stand by my own britches and I commend others who do the same.
RTP (Real-time Transfer Protocol, defined in RFC 1889) was designed exactly because of these problems, as I remember. And RTP specification seems to be from january 1996...
Speak Freely (http://www.speakfreely.org) others have mentioned uses RTP, and probably most other telephony libs/applications. As to UDP, there's nothing preventing people from developing protocols above UDP level, so that shouldn't prevent telephony either.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
http://www.i-link.net -- uses your normal phone, just needs your browser to start the actual hookup. Look for the TalkFree button in the bottom left corner.. No banners; apparently they have excess bandwidth and they're letting people use it for free long-distance phone calls across the contiguous 48 US states. I know this isn't really "telephony" but it's a GoodThing(TM).. web-based solution that is compatible across different computers.
-----
Linux user: if (nt == unstable) { switchTo.linux() }
Those who laugh at you for you having a Mac.. are the people who constantly call you to fix their PC.
Data Connection almost certainly provide exactly what you want. They do a total package - app sharing, video, audio, whiteboard, chat, the works. The relevant web page is here.
Gerv
Your experience exactly mirrors mine. I had no desire to go up against Dialogic's (crappy) tech support, except that the non-existent documentation for my cards forced me to. It seemed that the tech support people had the same documentation as me, but very little in the way of problem-solving skills. I know that Dialogic has developers squirrelled away somewhere in their operation. Unfortunately, their ability to develop new hardware far outstrips their capacity to write bug-free drivers for, document, or provide adequate tech support for that hardware.
Slightly more than one tenth of a second latency is not noticeable in a voice conversation. The final delay will be the one-way network latency + the sample length (in time), which if kept short enough can keep the lag from becoming too annoying. The half-duplicity of the modem connection does not go against my argument - in my calculation I took into account that both sending and recieving channels would have to share the pipe. Read it again if you think I'm bs'ing.
The poster to whom I was replying made a direct analogy between pirating software and using VoIP apps. My point is that it is possible to have a VoIP communication channel that is more effiecient than a regular analog phone call.
--Tim
Vovida has an excellent suite of GPL'ed IP-telephony stacks (H.323, SIP, Megaco, RTP, etc..). We are using them in our products.
This is probably too late to get noticed but....
Take a look at the OpenH323 effort at www.openh323.org, they have a well thought out, open source, cross platform H.323 stack that is being used by lots of people and is one of the most robust stacks available. In short, it's the dog's danglies.
Contrary to what a lot of people are saying in this discussion, H.323 is real, it works, and it is already in use. Sure it's not going to work great running of you Soundblaster over a congested 33.6 link, but given the right hardware and the right network it works perfectly!