Cross-Platform Internet Telephony? 75
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."
You couldn't have searched very hard (Score:4)
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? (Score:2)
After all, if it's written in java, that would be one of the key advantages. btw, did you look on computer telephony [computertelephony.com] magazine?
w/m
Sorry, shoe old pal (Score:1)
--
Re:Check out www.microsoft.com (Score:1)
The internet isn't made for voice calls. (Score:3)
RIGHT ON (Score:2)
ANTI TROLL ON THE PROWL (Score:1)
Java Telephony (Score:3)
LinuxTelephony.com (Score:5)
is a good place to start.
ANTI TROLL BRINGS THE CL00 TRAIN (Score:1)
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.
Video conferencing? (Score:1)
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
Re:Why linux? (Score:1)
". So far, solutions like HearMe and OpenH323 are either incomplete, lack quality, are not cross platform..."
was that it is going to be availiable for both.
Re:Abusing the telcos (Score:3)
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 --
Re:The internet isn't made for voice calls. (Score:3)
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. (Score:4)
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 [cisco.com] 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.
--
www.dialpad.com (Score:1)
dynamicsoft (Score:1)
Re:The internet isn't made for voice calls. (Score:1)
so voice over ip works.
if you know swedish you can find more info on http://www.teli a.se/bvo/info/gen_info.jsp.html?OID=72622&CID=-23
Check out Dialogic's DM3 solutions (Score:1)
mostly server side platform (Score:1)
bad question (Score:3)
<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 (Score:4)
http://www.quicknet.com [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 [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/ [sourceforge.net]
Re:The internet isn't made for voice calls. (Score:1)
It all comes down to the old chestnut that IP is a best effort service, and the need to find a scalable solution that allows the reservation of bandwidth (Diffserv is scalable, but does not allow bandwidth reservation, only relative QoS, wheras RSVP allows bandwidth reservation but does not scale well).
regards, treefrog
Write a good interface (Score:1)
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
IPv6 anyone... (Score:2)
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:-)
ANTI TROLL KEEPS SLASHDOT CLEAN (Score:1)
Re:Video conferencing? (Score:1)
I know of only one, that is freeware, though.
It's address is:
http://www.techcen.zgrad.su/prod/prodp.phtml?pa
or http://www.freeware.ru/screen.html?id=1927
it is in Russian, but I guess if you poke around you'd be able to see what's what.
Don't Bother - Their Heart Isn't Really In It. (Score:1)
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 (Score:1)
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.
Re:Don't Bother - Their Heart Isn't Really In It. (Score:1)
Voice over IP... (Score:1)
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...
Re:Video conferencing? (Score:1)
Great idea! (Score:1)
With good sound quality and high reliability at last I could dial my ISP to access the net!
Re:Check out Dialogic's DM3 solutions (Score:1)
While, I'm on my rant, their documentation is rather dissapointing. For one thing, they demonstrate everything as C state machine examples. Hey Dialogic, ever heard of multithreaded C++ applications? For another thing the help file , is loaded with MOTO comments (Masters of the obvious) with very little in the way of explaination or insight. I mean I can read the header file and get as little info as they provide about programming their API.
Re:bad question (Score:1)
Hahahaha. To paraphrase a former VP candidate: "I know Java, and you're no Java guru". Puhleeze. If I hear "slow" and Java in the same sentence one more time I'm gonna puke. If you'd been paying attention (and like me, attended JavaOne 2000) you'd know how wrong you are. Heck, as I type this I'm running a Java video capture program. But thanks for playing.
Re:Why linux? (Score:1)
He said that linux and Windows are BOTH a MUST... there is no question about cross-platformness, it is required. It's merely a launch-platform issue: and here it also makes more sense why to launch on linux as opposed to on windows: precisely because the demand will probably be smaller it will be easier to fix bugs and distribute new beta-versions. Additionally, I think linux users are perhaps more capable at debugging since developers form a larger percentage of the user base.
Re:The internet isn't made for voice calls. (Score:1)
G.728 and G.729 (Score:1)
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.
Re:Abusing the telcos (Score:2)
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
Re:The internet isn't made for voice calls. (Score:2)
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.
Runtime-customizable interfaces; Asterisk PBX (Score:2)
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.
Be sure to use SIP and Open Source it! (Score:1)
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).
I can't believe this question (Score:1)
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.
Re:The internet isn't made for voice calls. (Score:1)
Agreed. The Internet (Captial "I") can't cut the mustard in terms of QoS. Right now, the real advantage of VoIP is to offload high-traffic circuits onto a dedicated IP link. Think of a company linking multiple branch offices over dedicated pipes. I've used many 1.55Mbs T1's carrying dozens of conversations at CDMA quality or better.
J.Codecs (Re:Abusing the telcos) (Score:1)
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).
Major Caveat (Score:2)
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
All Java solution at CMU (Score:1)
www.ini.cmu.edu/eclub [cmu.edu] 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.
Re:Why linux? (Score:1)
I can't believe you people still _believe_ that anyone is going to want to do this. If you _pay_ for software it should work. If it breaks, the company should fix it.
You think everyone will want to do this. Have _you_ ever paid for broken software and spent the time learning, debugging, patching, and then submitting? Who has the time for this? Every minute you spend trying to fix someone else's broken software is costing your company money. So now you're not only paying for broken software, but essentially you're paying to fix it also.
Additionally, I think linux users are perhaps more capable at being clooless since the clooless form a larger percentage of the user base.
The voice of experience (Score:5)
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
Dude, you rule. (Score:1)
---
You're the developers=go develop it... (Score:2)
Re:The voice of experience (Score:1)
I was at CTExpo in LA in '99, trying out teh various vendors VOIP solutions. They had these quaint little phone booths where you could make a free call. Well, I called home and couldn't even recognize the voice of the person on the other end. Yes, the words go through, but all other communication was lost. And the lag was unbearable.
What's the point of all of this compression and stuff to send voice of ip, when there's already a hell of a lot of dark fiber in the ground, and more is being laid as we speak..and DWDM systems are improving how much bandwidth the fiber has. I tell you, its all in the switching. Some people don't want to pay for quality switches and would rather have their calls dirt cheap or free. Well that's fine if you're going to horse around. Personally, if I got a business call from someone and couldn't understand them because of the crappy quality of th VOIP connection, I'd think twice about doing business with them.
Ever used an ISDN phone? They sound great. Because this is digital telephony that works. We need to push ISDN or possibly DSL out to the home for telephony, not cram it over the Porn Pipe (internet).
Re:bad question (Score:1)
On a more theoretical note, Java will always be an interpreted language. Interpreted languages will always be slower than compiled once. Yes you can use JIT, but then you have to wait for the program to compile/assemble/whatever before you can use it.
Re:The internet isn't made for voice calls. (Score:1)
SIP and MGCP baby. Kick those huge euro standard bodies to the curb and get with the IETF.
Re:The internet isn't made for voice calls. (Score:1)
Re:IPv6 anyone... (Score:1)
As far as things like mobile phones go, they don't give such good performance as PSTN. On a scale from 0 to 5 with 4 being about PSTN quality they tend to come in a bit under 4. Besides, one of the more important applications for VoIP is sharing bandwidth between (and integrating) data and voice networks. Mobile phones don't address the issue there, they merely change the transport for the voice network.
Isn't that what RTP (RFC 1889) is all about? (Score:1)
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.
Re:bad question (Score:1)
Re:The voice of experience (Score:2)
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
SIP home page, great FAQ and Links. [columbia.edu]
Alright H.323 starter [databeam.com]
Open source H.323 effort. [openh323.org]
SIP-T starter. [softarmor.com]
For Real world examples try Dialpad.com, www.talkopia.com, etc, etc.
Re:Major Caveat (Score:1)
Re:The internet isn't made for voice calls. (Score:1)
Actually, you already see VOIP handling a lot of overflow traffic in the phone system, as well as being adopted by certain corporations.
already an easy solution (Score:1)
-----
Linux user: if (nt == unstable) { switchTo.linux() }
Data Connection Ltd. (Score:2)
Gerv
Amen, Brother! (Score:1)
Re:The voice of experience (Score:2)
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
[1] Call Detail Records
=RISCy Business
Re:The internet isn't made for voice calls. (Score:1)
And the delay between sender and receiver: if you choose it too small, a lot of packets will be lost (due to varying delay, only the fast packets will arrive in time) - if you choose it too large it's getting very nasty for the human user.
Re:Abusing the telcos (Score:1)
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: Free Stacks (Score:1)
Re:IPv6 anyone... (Score:1)
english of the author of your sig.
"The easiest way to be shot is to threaten a gunowner."
Re:Check out Dialogic's DM3 solutions (Score:1)
Re:Check out Dialogic's DM3 solutions (Score:1)
Tech support is much better than Dialogic (not that it could be much worse), as is the documentation and APIs
Look at http://www.aculab.com [aculab.com]
Re:You couldn't have searched very hard (Score:1)
Re:The internet isn't made for voice calls. (Score:1)
Re:The voice of experience (Score:1)
I say "standard" because a lot of international and long distance traffic is already going over VoIP and you probably don't realise it. I believe that international carrier VoIP traffic passed a million minutes last year, not much in the scale of things but getting there.
Try OpenH323 (Score:1)
This is probably too late to get noticed but....
Take a look at the OpenH323 effort at www.openh323.org [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!