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."

Comments

You couldn't have searched very hard

[FascDot Killed My Pr]

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).
--

Why linux?

[w00ly_mammoth]

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

The internet isn't made for voice calls.

[revin]

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.

Re:The internet isn't made for voice calls.

[Th3 D0t]

Ever get a "this circuit is busy" message on the phone? IP is more alike to modern telephone networks than you realize. Many (especially long distance) lines are packet switched virtual connections just like TCP/IP. Telephone and IP frequently both rely on packet protocols like X.25 and ATM.

The problem with TCP isn't because it is too slow, but because audio data is temporal. If a router went down somewhere for a few seconds, you don't want hear in fast-forward what the person was saying by the time it gets there. Audio packets have a time dependency after which it just doesn't matter. And as far as UDP, simple retransmission mechanisms are usually built in at the application level to deal with short-term packet loss and reordering.

The only big difference that pertains to your points is that the telephone networks typically have QOS contracts per connection that ensure that each connection will have the required bandwidth and latency needed, whereas internet does not have QOS or priority.
---

Re:The internet isn't made for voice calls.

[softsign]

There is a protocol redesign in the works. That's what Internet2 is being designed for. And I don't mean IPv6.

A lot of the big guns out there are busy developing infrastructure that will allow reliable Voice over IP, real-time video conferencing and other delay-sensitive apps to work reliably.

Cisco's Packet magazine had an article on this a while back (it was the cover story on the last issue). I'm sure there are dozens if not hundreds of other articles on this too.

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.

--

Re:The internet isn't made for voice calls.

[arivanov]

You are historically correct. Internet was not made for voice. For modern netrworks you are practically correct.

It is a very interesting situation:

Namely, most core networks are not heavily congested now. Reason for this is that at the packet rates in question routers have almost no buffering and even the smallest congestion leads to very ugly packet loss and users waving SLAs at the ISP. So, theoretically, there is no problem to run small scale voice over most cores now as it does not encounter congestion and the original design considerations you have layed out are void.

At the same time as we all know end-user voice is a problem. But the reason for this is usually lack of QoS at the end-user entry/exit or the last (small/medium/dialup ISP) tier before the end-user. If this bottleneck is solved which is not a problem for a properly setup office networks and VPNs (if the admin has a lot of clue) you can happily run office to office voice as well as home to office voice.

RIGHT ON

[Anonymous Coward]

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

Java Telephony

[mflagg]

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/

LinuxTelephony.com

[paled]

http://www.linuxtelephony.com/

is a good place to start.

Re:Abusing the telcos

[tsmith213]

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?).

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 --

bad question

[abes]

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.

Several Linux Solutions

[nodvin]

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/

IPv6 anyone...

[MosesJones]

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:-)

Re:Abusing the telcos

[arivanov]

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 ;-(

Runtime-customizable interfaces; Asterisk PBX

[cduffy]

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.

Major Caveat

[frantzen]

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 ;)

The voice of experience

[RISCy Business]

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

Re:The voice of experience

[gid-foo]

Some comments on the following;

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

H.323 is indeed bandwidth intensive. It takes a number of nailed up TCP(!) connections to maintain a 323 call. However, H.323 v1 and v2 do not support call connects over UDP. It wasn't until v3 that UDP based communication came in to play. SIP supports both TCP and UDP connections. It also greatly reduces the number messages needed to set up a connection between endpoints.
If you look at SIP and MGCP (IETF equivalents to H.323) there are a number of efforts to put in SS7 interoperability. ISUP traffic over SIP is in place today. And there are products available to do this. (See SIP-T which is SIP-Telephony interoperability). I'm not a huge fan but you might also want to look at http://www.softswitch.org/. Their are a number of companies attempting to build class 5 switches based on VoIP technology (see IPVerse, XyBridge, Lucent, etc).
If you're interested in AIN functionality over IP you can try the Generic Data Interface (Bellcore SR-3389). This is all North American. For ITU/ETSI you'll have to go do the legwork, I'm not sure there's anything specified.

To sum up, if any of you out there are actually interested in the current market for VoIP and the capabilities, go do your own legwork. Don't listen to one isolated experience on /.. The large majority of people in telecoms know jack shit about internet technology, and the same goes for internet folks coming in to telecoms. I'm not claiming that you don't know what's up RISCy, just that 1998 is eons ago in this industry and things are changing rapidly. The VoIP industry is blowing up right now and there's a lot of heavy shit going down. I highly recommend it to anyone interested in protocols. Here are some links:
SIP home page, great FAQ and Links.
Alright H.323 starter
Open source H.323 effort.
SIP-T starter.

For Real world examples try Dialpad.com, www.talkopia.com, etc, etc.

Re:The voice of experience

[RISCy Business]

You have NO idea how refreshing it is to see intelligent replies. Especially the way /. is these days. ;P

Yes, '98 is eons ago. When I spoke of H.323(v2), I did mean only the call routing/gateway functionality, which is UDP for the route *only*, and then uses TCP. This WAS an early version of both, however, so they may have changed it.

It didn't take me long to see that VoIP is years and years away from functional maturity. Really, the problem lies within the maturity, or lack thereof, of VoIP. The standards are not set in stone, interoperability is non-existant, transmission and recieving standards are non-existant. Manufacturers? Agree on gatekeeper applications? Please. Call accounting is typically done via Radius CDR[1]s, which is incredibly ineffecient and unnecessarily complicates accounting functions.

Honestly, I'm more of an Internet guy than a telecom guy, but I also got stuck managing and provisioning most of the network, as well as the in-house PBX systems, so I've got a good amount of knowledge about both. Either way, lying fiber only does so much good. As broadband expands, you're going to see that available bandwidth snapped up faster than they can bury it and light it, leaving little to no room for additional things, like VoIP and such.

I don't think VoIP will take off till the providers get the clue and start building private interconnecting networks between PSTN termination points and internal origination/PSTN origination (ie; for calling cards) points. And until full SS7 interconnect on all fronts is a reality, call routing will remain an unwieldy, bulky, unnecessarily complex and obscene task, which is best left undone. (You can't store the entire NPA-NXX tables for all the US, or even all of a single state, within any current hardware VoIP solution. They all require an external gatekeeper.)

VoIP is an immature system and far far from being production and carrier quality. Especially the PC-based solutions. Until people realize that you have to follow very strict network design and maintenance principles, it's going to remain that way, but those are just my thoughts and opinions. YMMV.

Good to see some intelligent discussion on /. once again - maybe it'll continue! :)

[1] Call Detail Records

=RISCy Business

You're the developers=go develop it...

[TwoEdge77]

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.

Data Connection Ltd.

[Gerv]

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