Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Letters
   

  August 19, 2002
 


TOC Issue TOC
Printer Print full article
E-Mail E-Mail this URL
flameauthor Flame the author
"The real reason you can't justify VoIP isn't necessarily the cost, but quality." --Jay C. Carter, Washington State Employees Credit Union



Can You Hear Me Now?
I agree with David Willis in his July 8 column ("How Will We Justify VoIP?"), in that the instrument used to make calls should be improved. However, the real reason you can't justify VoIP isn't necessarily the cost, but quality.

A few months ago, I took part in a large, international user group that had many breakout sessions about VoIP. There were some attendees from organizations that support companies with Gigabit Ethernet networks and fiber optics and all the other good stuff. They said the same: The functionality of their standard voice set does not translate to a VoIP phone with the same quality and consistency. This is not the fault of the phone but the fault of the way VoIP is represented in the network structure.

It would be great if the phone were a node on the network, capable of sustaining a connection, as on a PC, and had a better interface that would let you use some of the functions Willis talks about. However, when you can't transfer a call from an IP phone because of network traffic, what the phone looks like and its bells and whistles don't matter. It's useless.

Once we can build a VoIP network that has the same standard communication ability offered by a traditional voice system and that delivers 100 percent of a traditional voice system's base functions 100 percent of the time, then we should talk about how to move the telephone further along. And when we do start moving it along, maybe we'll find out that all those functions Willis talks about putting on an IP phone are also available on a traditional voice set, and we really don't need VoIP at all. As Willis says, in most cases renegotiating your rates with the carrier is cheaper than reconfiguring your network to make VoIP work as it should.

Jay C. Carter
Information Services Administrator
Washington State Employees Credit Union
jcarter@wastatecu.org

David Willis responds: You've made a couple of good points here. We could debate about what constitutes quality voice, but it's really a matter of perception. Pops and clicks are OK for some; international users, for example, are used to them. In the United States, we're accustomed to better quality for landlines, though we have lower expectations for our cell phones, even lower than the Europeans do.

Nonetheless, I think quality is getting better. It's not really the quality of the codecs, echo cancelers, silence suppressors or the packetization techniques that are now the issue -- the big problem is the quality of the data network on which you overlay the voice systems. Even PCM voice at 64 Kbps is not a lot of bandwidth, and that would give you toll quality. None of the production VoIP deployments even bother with codecs under 16 Kbps. But latency and loss are the real issues for converged networks, and trying to ensure low latency and loss across every point in a large data network is tough.

Regarding feature sets, clearly they're not the same on the IP PBXs. Arguably, many features are unnecessary, and many more would be employed if users could understand and access them.




Hire Learning
As a young but very talented network services firm, we may have read Jonathan Feldman's article
"Hire Authorities" from a different angle than your primary audience, but we found it useful. I plan on dissecting it further to learn a few things. Thanks for thinking this topic through.

Ben L. Waddy
MCSE Territory Sales Manager
American Control Systems
bwaddy@americancontrol.com



HP/Compaq Revealed
I read Rob Preston's June 10 column,
"Wrestling With Indecision," and was reminded that all the "pundits" missed the why of the Hewlett-Packard/Compaq deal. If the deal had not gone through, Hewlett-Packard and Compaq would cease to have meaningful presences as big-system vendors. Reasons:

1. As punishment for Intel's (Pentium) having violated Digital Equipment (Alpha) patents, Intel had to take over running the Alpha fab factories (obsolete and expensive).

2. To balance this punishment, Intel was granted royalty-free access to the entire Digital Equipment patent portfolio.

3. Compaq bought out Digital Equipment service, and Digital threw in the balance of what was left (such as patents and Alpha systems that no one was interested in partly because of Nos. 1 and 2).

4. HP needed a 64-bit replacement for its obsolete PA-RISC to stay viable in the large-systems market.

5. HP got into bed with Intel for Merced/Itanium/McKinley or whatever it will be called and promoted the idea that HP is a co-inventor of that chip.

6. Compaq had no real capacity to develop large systems (dwindling Digital engineering staff, no ability to make CPUs), had a bumpy relationship with Intel and was unable to get AMD or other x86 vendors to go 64-bit.

7. HP realized that as "co-inventor" of Itanium, it was at a significant disadvantage over the other co-inventor, Intel; HP had no access to the patent portfolio held by Compaq (to which Intel had complete royalty-free access) -- big problem!

Solution: HP bought Compaq (and hence the patent portfolio) to ensure that it can afford to be co-inventor of Itanium.

LD Landis
President
Rosecroft Associates
ldlandis@ldl.HealthPartners.com



CORRECTION
Darrin Woods' July 22 Sneak Preview, "Akara OUSP 2000 Goes the Distance With Fibre Channel," should have stated that the OUSP 2000 does not perform QoS on Ethernet circuits at all, and pre-emptable bandwidth cannot be shared between circuits. The starting price for the product is $20,000.

Tell Us How You Really Feel
Send e-mail to editor@nwc.com, fax to (516) 562-7293 or mail letters to Network Computing, 600 Community Drive, Manhasset, NY 11030. Include your name, title, company name, e-mail address and phone number. All correspondence becomes the property of Network Computing.



Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers