January 2002

Reality Check On VoIP

BY DAVID BREGMAN

When we talk about voice over IP, we must realize that it means different things to different people. For some it means VoIP phones at every desktop with universal follow-me numbers; for others it is integration with the existing PBX (IP-PBXs) to provide a mixed environment. With so many definitions and ways to deploy VoIP, it is no wonder that we are all confused. 

The goal of VoIP has been to enable the enterprise to create one heterogeneous IP network to handle all voice and data traffic, alleviating the need for separate discreet networks. While voice over frame relay (VoFR) or voice over ATM (VoATM) in the enterprise have gained acceptance, these implementations still require discrete networks to handle the voice traffic.

A few years ago, VoIP was the answer to all our problems. Falling IP access charges, high PSTN circuit costs and the promise of advanced features made for a rosy outlook. Many of us would have predicted that by now we would see every call center using VoIP with advanced voice-enabled Web pages. We imagined road warriors using voice over IP enabled browsers to place calls virtually for free from any location. Thanks to VoIP we would all have a single follow-me number with unified messaging, including converged voice, fax, and e-mail accessible from the Web or a phone. Our telco budgets would be halved and there would only be one converged IP voice and data network to manage.

Back To Reality
This is not what happened. As IP costs fell, so did toll-quality calling costs. It is fair to say that as of today VoIP has not taken off as expected. While some of the aforementioned features are available as services from a few providers, VoIP implementation is expensive and largely unreliable. Established carriers are largely relying on the tried and true PSTN network. It is only the emerging carriers that are investing heavily in VoIP. These �VoIP pioneers� don�t have a large investment in legacy network equipment and have over-provisioned their backbone so much in the last few years that they have excess bandwidth on which to carry voice over IP traffic.

For the enterprise, it is often cost-prohibitive to deploy voice over IP. Most enterprises have a huge investment in their current PBX technology. Add to this the major budget reductions for network IT infrastructure and we begin to see some of the stumbling blocks for enterprise implementation of VoIP. There are many additional issues to contend with.

Interoperability
There is still no clear winner in the standards war. H.323 has gained early acceptance but SIP (Session Initiated Protocol) is right on its heels. MGCP has been slow to gain ground and many see it as too vendor-specific. There is a great variety in the way different vendors implement each standard as well. Recent independent tests of SIP implementations have shown that most vendors could achieve basic interoperability, albeit with some tweaking of the code. When it came to advanced functionality they did not fare as well.

Security
There are basic security questions to be raised about sending voice traffic over a public network. Additionally there are firewall issues to contend with (although SIP has gone a long way to make the firewall issue moot.)

Advanced Features
One of the major promises of VoIP is its ability to offer advanced features. As mentioned above, the industry is not quite there when it comes to interoperability between vendors. Even in single vendor implementations, there is the major issue of 911 service. In most municipalities, buildings over a specific size must be able to transmit the physical location of the caller to the 911 system allowing emergency personnel to locate the caller. In a traditional PBX environment, this problem is solved by matching the directory number to a physical wire connected to a port that can be located in the building. With voice over IP this does not exist and therefore it can be difficult, if not impossible to locate the VoIP call point of origin. Vendors are working on this, but no clear standard or solution has evolved.

Quality Of Service
QoS is as misunderstood as VoIP, but is an essential component to any successful voice over IP implementation. Without some sort of QoS mechanism VoIP can be rendered useless. QoS in a voice environment relates to delay, packet loss and jitter. Combined, these factors make a VoIP implementation fail.

Link overutilization is the major QoS culprit. If the link used to carry VoIP is overutilized then voice traffic will suffer. This is the same for any application traversing the link but voice, by its nature, is particularly susceptible to link utilization issues. An overutilized link will often cause delay, packet loss and jitter.

Delay: There is inherent delay in any network due to the speed of light. The longer the run, the greater the delay. A general rule of thumb is that for every 1,000 miles, 10 ms of delay is added to just transport the data. This may not sound like much, but keep in mind that the generally acceptable maximum total delay for VoIP is 100ms. If you are calling from New York to London (3,500 miles apart) you are adding almost 35ms just due to physical distance (this assumes that the packets will take the most direct route, which rarely happens.) Further delay is introduced in the processing of the voice packets (encoding and decoding), routing of the packets and due to congestion on the line. A link that is congested will add significant delay over one that is not congested. This delay increases dramatically with increased congestion. For example a 64 byte packet on a 128 Kbps link with 40 percent utilization might experience a 7ms delay. When the utilization is increased to 80 percent that delay increases to 20ms. Therefore it is important to make sure that the link containing your VoIP traffic is not overutilized. There are steps that can be taken to identify voice traffic so it will be treated favorably in the backbone; these include DiffServ tagging, MPLS tagging, and manipulation of the TOS bit.

Packet Loss: Packet loss typically occurs due to congestion on the link. Packet loss greater than five to ten percent can make VoIP unusable. Some packet loss is inevitable in any packet-based network. The goal is to reduce this loss as much as possible. There are techniques in use to reduce the sensitivity to packet loss through the use of smaller packet sizes and interpolation. Another effective method for reducing packet loss is to ensure that voice packets get priority over other packets traversing the network link, thus ensuring that they are not dropped.

Jitter: Jitter is the amount of variation in packet delay from one packet to the next. Jitter makes voice quality choppy and difficult to understand. Most VoIP gateways contain a jitter buffer to introduce a slight delay into each packet to better control overall jitter, but this oftentimes makes the conversation sound unnatural by introducing an artificial delay. Again, by reducing the congestion on the link, delay is reduced and therefore jitter is reduced.

Why Bother?
Looking at all of the above arguments, you might ask, �Why even bother?� There are many good reasons to consider voice over IP for the enterprise. Among them: The fact that VoIP helps companies begin to integrate corporate data applications with voice applications; it can bring significant savings on international calls; and VoIP allows enterprises to take advantage of under utilized infrastructure. Many enterprises can benefit from taking advantage of their current infrastructure by deploying VoIP on an ad hoc basis via IP-PBXs. In this way they can take advantage of underutilized bandwidth to make some calls. VoIP is used to augment the existing PSTN, allowing the enterprise to save money without great risk.

In these ad hoc VoIP implementations, voice is traveling on the same network as critical business applications (ERP, CRM, etc.) along with less critical applications (Web surfing, e-mail, real audio, etc). In these converged voice and data networks, QoS becomes even more critical so a balance can be struck between the voice and data traffic. Many times you want to be able to guarantee bandwidth for voice, while leaving enough free bandwidth to ensure performance for critical applications. In these situations you may need to actually limit the number of simultaneous conversations, while being able to guarantee enough bandwidth for each individual conversation.

In the example, we have a 128k WAN link to handle voice, Oracle, Peoplesoft, and all other data traffic. A balance is needed between voice and the other traffic. We need to create guarantees for the critical data (voice, Oracle, and Peoplesoft) and limits for the non-critical traffic. Furthermore, we need to guarantee each voice conversation to ensure that we do not have too many simultaneous calls creating poor quality for each call. This can be accomplished by creating an application committed information rate (A-CIR) for voice, Oracle, and Peoplesoft. An A-CIR is similar to a CIR found with frame relay circuits except that it relates to a specific application. In this case, we need to be even more granular and create an A-CIR for each voice conversation. In this way we can not only guarantee 64k in bandwidth for voice, but we can also make sure that each conversation, or call, gets a guarantee of 16k; ensuring minimal delay, jitter, and packet loss.

With proper QoS mechanisms and careful planning, voice over IP can be rolled out today to supplement existing PSTN PBXs. To a large extent this creates the best of both worlds: One can take advantage of reduced international toll rates, cutting monthly recurring costs; leverage existing infrastructure, and get a return on the investment that was made over the past few years; and gain valuable VoIP experience for future deployments. This is achieved while retaining the reliability of existing PSTN PBXs. c

David Bregman is a senior technologist with NetReality, a premier provider of network application priority switches (NAPS). NetReality�s technology enables organizations to prioritize mission-critical voice and data traffic on their wide area networks. He is looking forward to when his eight phone numbers will be reduced to one follow-me number.

[ Return To The January 2002 Table Of Contents ]

Carriers around the world are looking for more efficient, cost-effective alternatives for routing their international voice traffic. Enter iBasis, a voice services provider based in Burlington, Massachusetts. The iBasis Network � one of the world�s largest international Cisco-powered Internet telephony networks � is a global VoIP infrastructure that leverages the attractive economics of Internet-based communications to route calls around the world at greatly reduced cost.

Providing wholesale international Internet telephony services, iBasis enables carriers to reap the advantages of VoIP without the investment in time, money, and staff. With dozens of the leading carriers in the U.S. and abroad on their client list, iBasis clearly has the right service at the right time. The key to its profitability, however, is striking the right balance between Internet economics and carrier-class quality. After all, if a fax sent from Chicago arrives in London or Beijing as a garbled mess, the customer won�t be happy and the cost savings becomes irrelevant. 

�Our goal is consistently to achieve the best, most cost-effective connectivity possible among our POPs around the globe,� explains Paul Skelly, manager of network performance for iBasis. �For our carrier customers, call quality is non-negotiable. If we can�t achieve the right quality over the Internet, we use alternative routes that will. However, these �off-net� routes may cost us more to use than an Internet route. In fact, because we guarantee service quality for our customers, we could lose money on a call that we cannot route over the Internet. So having accurate, real-time measurements of Internet call quality is of strategic importance.�

The Build Versus Buy Decision
Initially, iBasis set out to develop its own network measurement infrastructure. Led by Skelly, the development effort did produce some useful tools. However, the cost and complexity of building measurement tools on their own soon became clear.

�We didn�t want to create a development quagmire that demanded additional staff,� Skelly said, explaining why iBasis started looking for off-the-shelf solutions. After evaluating a number of commercial systems, iBasis found the right technology partner just up the road in Chelmsford, Massachusetts, at Brix Networks, a provider of real-time, Internet service assurance and performance measurement solutions.

�The Brix network verification solution was truly carrier-class: robust, easily managed and very scalable. As a global provider to major carriers, with more than 580 POPs around the world in more than 80 countries, this was critical to us,� Skelly says. �The system has robust data collection, data warehousing, and provisioning capabilities. And it has carrier-grade interfaces, which simplify network integration.�

Turnkey Internet Verification 
Initially, iBasis installed Brix 1000 Verifiers in its 11 Internet Central Offices (ICOs) around the world, managing this distributed system with BrixWorx central site software in its Network Operations Center (NOC) in Burlington. The Brix System is integrated with iBasis� own proprietary Assured Quality Routing (AQR) systems and provides end-to-end monitoring and measurement of call quality between POPs along multiple paths, aggregating a variety of fundamental performance metrics � including packet loss, delay and delay variation, or jitter � to help the company�s AQR systems identify the best path for the call. This analysis is performed, and the results are presented in the iBasis Network Operations Center (NOC), in near-real time. The Brix System also measures availability and performance of H.323 and other call setup services, which often involve multiple cooperating servers and applications. In addition to providing per-path call quality measurements, the system provides proactive warnings of call setup outages, enabling providers like iBasis to take action before service is impacted.

Eyeball On The Internet
Up and running for more than six months, the Brix verification solution has become a critical link in the iBasis Network, according to Skelly.

�Brix is our eyeball on the Internet. Working together with our Assured Quality Routing systems, it helps us understand when we can and cannot use the Internet for routing voice traffic,� he says, noting that in addition to the system�s real-time analysis capabilities, it produces valuable historical data. �We�re using the data to make network architecture decisions right now. In the future, I think it may be helpful in making business decisions impacting network expansion plans and perhaps, even in setting rates.�

[ Return To The January 2002 Table Of Contents ]