Zibb

News and New Products

Voice over IP problems persist

By Ed Sperling, Editor in Chief -- Electronic News, 7/20/2007

Electronic News/Electronic Business sat down to discuss the future of voice over IP with Brian Glinsman, general manager of communications infrastructure and voice at Texas Instruments; Bryan Martin, chairman and CEO of Packet8; Jeffrey Rodman, co-founder and CTO of the voice division of Polycom; and Alan Weckel, financial analyst at Dell’Oro Group. What follows are excerpts of that conversation.

Q: What’s wrong with voice over IP? Sometimes it works, sometimes it doesn’t, and that’s not good enough for many people.
Martin: One of the main differences between voice over IP networks and traditional approaches to voice networks is that you have a lot more single points of failure in voice over IP. There is very complicated and advanced customer premise equipment. There is a local area network that can have conditions affecting the transport of data. There is the last-mile connection and a backbone connection. Conditions in any of these can affect quality of services.
Weckel: And because it’s a newer technology, the ability to diagnose where the failure is hasn’t reached maturity. Voice networks have had decades to troubleshoot and figure out where the problem is and how to fix it. A lot of times these VoIP overlays on networks are being done for the first time without IT staff, so it’s ‘hope and pray’ when you plug it in.
Rodman: When you talk about quality of service, there are three different things we’re talking about. One is reliability of the connection. Does the call go through or does it break down mid-way? There’s a gray region between that and packet drops, where you get momentary breakups of speech. The third thing is quality of experience.
Glinsman: Until the early 1980s, voice networks were a one-vendor solution. Historically, voice over IP started out as a cheap alternative with an uncontrolled network and a protocol that was a best effort. Over time, we’re changing the protocols. If you go back to the old PSTN (public switched telephone network), all the large carriers would run nightly automated testing of given circuits and they would take bad circuits out of use. It was a fairly controlled environment. Today, with IP (Internet Protocol), you don’t know where the bottlenecks are going to be in the network. It can change by the second or by the hour or by the route. Because the initial networks were all overlays over data for cost savings, they didn’t really care about quality. That’s given voice over IP a bad name even though it can actually be better quality. There also is a little more inherent delay, which may make the use of an echo canceller mandatory. With PSTN, if you keep the phone call within a country, echo cancellers aren’t needed. The cheaper you make the box and the less you do testing of the circuits, the more chances for a problem.

Q: Voice over IP is the convergence of voice and data. But as we go forward, it probably will include video and even cellular. Do the problems get worse because of that?
Rodman: Putting the question of gross bandwidth aside for the moment, some of the most critical issues involve voice. That’s the most sensitive to latency. It’s the most sensitive to dropouts. It’s very demanding. Once you’ve addressed that, you are ready for video. You may need to enhance the bandwidth, but you’ve got the media quality.
Martin: Today we mix video with some of our voice customers. With video, you have a lot more data, so there are bandwidth constraints. But the fact that you have more data makes recovery of errors and concealing errors easier. You’ve got the previous frame and the next frame. With voice, you can drop a 30-millisecond packet and they’ll hear the click. Ears are very sensitive to missing information. Eyes have limitations. As you converge voice and video, you have a combination that requires very different treatment.
Glinsman: As you converge them, the voice will actually improve. To do video, you need a much bigger pipe. The algorithms exist to give priority to one over the other. You can steal bandwidth from the video to protect the voice. If you look at some of the stuff done in cable with DOCSIS (data over cable service interface specifications) 2.0 and 3.0, they protect the voice channel because the voice is the most noticeable. We’re starting to see that become true in IPv6. The real problem in voice over IP is we have tons and tons of data, but it never makes to the end person on the network. That makes it hard to figure out what’s wrong with your network. If someone calls you up 10 minutes later, the network may have changed and you have no idea what happened. If you don’t have that information when the problem occurs, it’s really hard to go back and trace it.

Q: Where is the problem? Is it in the backbone or the connection to the home or office or the handset?
Martin: The problems can be anywhere. What we find is the backbone of the Internet is self-healing and generally very reliable. Unless you have one of the big events that’s going to make the newspapers—a virus or Internet worm or attack—you’re not going to see any degradation on the backbone. With most of our customers, the problem is isolated to the last-mile connection or the ISP providing the connectivity to that last-mile connection. When you go into the business world, the term ‘last mile’ takes on new meaning because you have that last mile Internet connection and a local LAN and maybe even wiring local to the buildings. We’ve had customers complain they’re hearing other voices on the line, and what happens is they’re utilizing the existing phone lines in the building to run from a wiring closet to a physical telephone, and the voices they’re hearing are cross-connected in the building’s wiring closet.
Weckel: We’re seeing a lot of problems in between exchange points, where you have an enterprise and a carrier and they’re not talking to each other about how to provision both sides of that connection for quality of service. The enterprise provisions it within their network and WAN connections to remote offices. But the minute they try to talk to a carrier, the dialog breaks down. The carrier doesn’t want the enterprise to know what they’re doing in their network, and the enterprise won’t tell the carrier what they’re doing in their network. So you have these two black boxes and a connection.
Rodman: The methods for taking an existing data network and making it quite capable are pretty well understood. It’s a matter of taking the hubs off the data network, cleaning it up, and making it VoIP-ready. There’s a step-by-step formula an IT manager can follow to clean up an enterprise. Once you get onto the external network, that’s where we see the issues happening. They need to adopt a much more protected media from site to site to maintain quality of service from building to building.
Glinsman: When you look at what we spend our time on at the lower level, there are issues about whether the call goes through and the quality during a call. Problems with getting the call through are almost always related to soft switches. You end up with one-way calls or the call not going through. That’s a definite problem. That’s getting addressed rapidly, because as people deploy, you find the problem, do a software release, and you’re now interoperable between two end points and you continue to move along.

Q: That problem has been out there for about 15 years, hasn’t it?
Glinsman: It has. The larger guys now work together pretty well. It’s when you get to the advanced features that you might have a problem. On the other side, when you’re passing the voice and you go to voice over packet and back to TDN (telecom design network), you have some potential for quality problems. That comes down to either a bad TDN—a free-floating clock—so on the VoIP network you have different clocks on both sides. You will take slips. When this is employed internationally, an echo canceller that works great [domestically] doesn’t work in these conditions.

Q: What happens when video comes into this? Is it just a question of more bandwidth?
Rodman: It adds even more accent to what happens in the building and what happens once you get onto the network, because within the building everyone is going to 100Base-T or gigabit Ethernet to the desk. You have backbones capable of an immense number of bits within the building, so with the proper architecture you are fine with VoIP and you can handle video without a problem. Once you leave the building, because you have these wide data streams that are going to hog the bandwidth, that becomes something you have to address. When you add a lot of video, you really have to take steps to address data engineering.
Glinsman: You have to be careful when you’re talking about video. Are we talking about two-way video or a video stream? Kids adopt things faster than anyone, but one thing they haven’t adopted is two-way video. Video streaming, absolutely. Conference bridges with 23 kids on it all talking, text-messaging, sure. But they have the capability in their PCs to do interactive video and that hasn’t taken off. We’re seeing more and more the drive for video streaming to the phone. When you do two-way video, video compression takes longer than the voice compression. You have to delay the voice to get it in sync with the picture, so you’re adding delay. The rule of thumb is, 50 milliseconds round trip, you need an echo canceller; 200 milliseconds round trip, you might as well not bother. All satellite phone calls stopped because of the delay.
Martin: You also have to consider how our usage of these applications is actually being shaped by the limitations of the broadband infrastructure. The fact that I can download megabits but I can only upload kilobits, even for a small business owner, automatically says I will not be a publisher of video content. Or if I am, I need to be very patient. Even in the still photo world, you get home from vacation and you have 48 5-megapixel images to upload to a site to get them printed, and that might take 30 to 45 minutes. As we see some of these next generation access technologies roll out or WiMax, which can get there wirelessly, but where there also is symmetrical bandwidth, the application developers will adapt and user behavior will adapt.
Weckel: Enterprises really are looking at video, whether that’s communications where you click to call and you go to videoconferencing, or whether you have high-def videoconferencing where it really looks like you’re in the room. But enterprises are looking at different levels of video, depending on who’s on the call. If you’re within your internal network, you can have high bandwidth. If you go off campus, maybe you drop to a different resolution. We have seen workers with video instead of just a soft phone on their laptop, and when they’re in their enterprise they’re doing up to 30 frames per second. The minute they go into their hotel room, that drops down to lower resolution and less frames per second.
Rodman: There are a couple of interesting dynamics here. The emergence of H.264 (video compression standard) is a much more efficient video compression. It gives the same quality picture for about half the bits. At the other end, what’s emerging is the move to high-definition videoconferencing. At the upper end of that is immersive high-definition conferencing. One of the things about high definition is there’s a growing consensus that it will end up at 1080p, 60 frames per second. By going to a higher video frame rate, your overall interactivity is drastically improved.

Q: But you still need a bigger pipe for that, right?
Martin: You need a huge pipe. You want to get to orders of magnitude where a piece of fiber isn’t just going to carry one high-def connection. The kids will watch theirs, you will watch yours, and the TiVo in the bedroom will be recording two additional ones. There are forecasts that the prices of camcorders that support high-definition will drop to the $200 to $300 range in the next year or two. Everyone will be running around with these streams and no capability to send them or share them.
Rodman: For uncompressed video, the bandwidths are very high, which is why you see a lot of movement toward UWB (ultra-wideband) for moving bits through the air. For business conferencing, because it’s compressed stream, a lot of it is done today in standard resolution at 384 kilobits. This is one of the big things H.264 enables, because it brings a lot of stuff down from 768 to 384 kilobits. When you move to high-definition videoconferencing, that number goes to 1 to 2 megabits per channel. It’s higher, but not orders of magnitude.
Glinsman: You have to distinguish enterprise versus home. The enterprise typically has significant bandwidth and can handle a few channels. In the small and midsize business—particularly those with less than 50 users—you tend to go back to the typical home broadband, and there video will cause you significant trouble. In the latest homes with fiber, that’s no problem. For DSL, uplink is not sized for video.
Rodman: I think the common terminology has dropped a critical letter. It’s still ADSL. It’s asymmetrical, but we call it DSL.
Glinsman: Cable has the same issue, but they hide it better. Their channel is higher speed, but it’s shared. Depending on how they’ve provisioned the network, you may get a 5 megabit speed, but not for very long.



Reed Business Information Resource Center

Featured Company


Related Resources

ADVERTISEMENT

ADVERTISEMENT

Feedback Loop


Post a CommentPost a Comment

There are no comments posted for this article.

Related Content

 

By This Author


ADVERTISEMENT

Knowledge Center


Events

10th R&D-Product Development Metrics Summit
Dates: 12/8/2009 - 12/10/2009
Location: Four Points Sheraton Hotel-Norwood, MA

Six Sigma Green Belt Training Certification
Dates: 12/11/2009 - 12/14/2009
Location: Chennai, India

Submit an EventSubmit an Event




Technology Quick Links

EDN Marketplace


©1997-2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites