Walled In

Posted: 03/2000

Walled In:
Why IP Voice is Held captive
(And, what Carriers, Vendors Are Doing to Set it Free)
By Charlotte Wolter

Level 3 Communications Inc. ( has made its reputation in transport
networking and on Wall Street as the advocate of pure IP networking. Yet when Level 3
hands off IP voice traffic to another carrier, even if the traffic is going to continue as
IP voice, it converts it to good old-fashioned time-division multiplexing (TDM) voice.

Level 3 is not alone. All major carriers convert most of their IP voice traffic to TDM
to do handoffs. However, this introduces significant delays in voice traffic, not to
mention the costs involved. Level 3 plans to exchange traffic in the IP realm as soon as
possible, says Ike Elliott, vice president, softswitch services, Level 3, "but there
are technical challenges."

Standing in his way, is a towering wall of nonstandard equipment, diverse types of call
detail records, multiple compression algorithms and call control protocols.

Quality of service (QoS) is the overriding issue, though service providers define it
differently. The international toll bypass clearinghouses, which use the public Internet
much of the time, do not have the expectation of providing toll-quality voice.

Still, they often exert Herculean efforts to maintain quality in the unpredictable ‘Net
environment. Those that want to provide large-scale IP voice to business, such as Level 3,
are looking for IP telephony that can pass muster in the most critical business

However, "Most carriers can barely assure quality themselves, so what happens when
you go from a Level 3 to a Rhythms (NetConnections,,"
asks Deb Mielke, president, Treillage Network Systems.

The standards for quality, settlement and monitoring that are well established in
circuit-switched telephony are nonexistent in IP voice.

The Barriers

The barriers to IP voice exchange range from QoS and monitoring to settlement and
billing. Few, if any, standards or even generally accepted ways to proceed exist for any
of these critical network operational factors.

"Quality of service is the most challenging, and it’s not so much an issue of
maintaining quality of service from one network to another. It is an issue of how to
maintain quality of service at all without just throwing bandwidth at it," says Gregg
Astoorian, senior manager, Internet telephony marketing, Nortel Networks Inc. (

"Level 3 has more bandwidth than God, but so what?" says Mielke. "The
networks buying from them don’t necessarily have a lot of bandwidth and the interconnect
doesn’t either."

Some of the proposed solutions to improve control over QoS, such as multiprotocol label
switching (MPLS) and DiffServ, still are not finalized as standards and have yet to be
adopted widely. In addition, they don’t address larger network issues, such as
interoperability among gateways.

There is no agreed way to measure quality, let alone a standard, as in circuit-switched
systems with their fixed 64kbps performance requirement. Many providers measure packet
delay and numbers of dropped packets, though there is no absolute link between those
figures and voice quality.

More qualitative means are under consideration, says Anthony Weber, project manager,
research and development group, RCN Corp. (
"It can be effective. It is just a matter of getting providers to accept that it is a
good way to measure."

Even if bandwidth is abundant, networks don’t always function smoothly. With IP voice,
if quality drops, there are few mechanisms to identify the source of the problem. That is
complicated by the fact that the customer may not know which network is carrying the

"How do you monitor if it goes through three carriers?" asks Mielke.
"You could buy IP telephony from (3)Voice by Level 3, an RBOC and a CLEC, and never
know it."

The ongoing, and so far unsuccessful, effort to resolve call control protocol standards
for gateways is possibly the most galling to network operators. Backbone network
operators, such as Level 3, favor the simpler session initiation protocol (SIP), while
media gateway control protocol (MGCP) is favored for more complex control, such as
communication between a gateway and gatekeeper (also called media gateway controller).

Most gateway vendors have adopted H.323, but the imprecision of the standard means
every iteration is different and not interoperable.

"The challenge is trading off traffic among networks," when each gateway
vendor is doing something different, says Jeff Zwall, senior product manager, IP services,
Williams Communications Inc. (
"And no one wants to buy the wrong box."

Lea King, product director, Concert Global Clearinghouse, a service of Concert
Communications Company (, says,
"Some of the more aggressive players, such as Clarent (Corp.,, rather than waiting for standards, are
implementing their own proprietary protocol and trying to grab market share."

The lack of standards among gateway vendors extends to call detail records. "We
have heard that Lucent (Technologies Inc.,
and VocalTec (Communications Inc.,
are interoperable," says King. "But that is a marketing statement, because, from
the service provider point of view, the call detail records (CDRs) are so different that a
settlement house such as us could not settle a Lucent record with a VocalTec record."

Mary Evslin, vice president of marketing, ITXC Corp. (,
says, "Today we collect CDR records from all platforms and sell to carriers. But the
way we have to do that is operate four mini networks, Lucent, VocalTec, Clarent and Cisco
(Systems Inc.,, and each terminating location almost always has more than
one company’s terminal."

Quiet Suffering

So far, carriers, with the exception of ITXC and Level 3, have not been vocal about
these issues. There is no industry group leading a charge for standards and
interoperability, with the exception of ITXC’s iNOW! effort, which began as an initiative
to get H.323 gateways to interoperate.

However, ITXC found the effort, which included interoperability testing, too draining,
and turned it over to an industry organization, the International Multimedia
Teleconferencing Consortium (IMTC,

Vendors, who originally predicted interoperability by third quarter 1999, now are
promising it by the third quarter of 2000.

The industry has not taken a strong position because, "The carriers are all trying
to grab market share," Mielke explains. "So they are not going to cooperate on
anything now. Everyone is getting into everyone’s space, and it is all about profitability
and market share."

However, Elliott points out, "Quality is a competitive issue, but I think there is
another motivation for exchanging traffic in the IP domain. Every time they do a
conversion from packet to circuit there is physical equipment that carriers have to

Besides cost, "Every time they switch from packet to circuit they are adding
latency … and that hurts the end-to-end quality of service," he says.

Mielke adds, "On top of all that, frankly the stuff that is out there isn’t ready
for prime time either from the carrier side to build infrastructure. So carriers are
building with half-baked stuff. It’s not ready. So in the carriers’ defense, that’s the
other side of the problem."

Because of these barriers, IP telephony has remained locked in two narrow business
niches: international arbitrage and backbone transmission.

"Though companies make a lot of money in international, we are at least two years
away from this stuff having a broad impact," says Mielke.

IP voice providers offer only a bare-bones service with few applications. "Tell me
one IP telephony service with caller ID," Mielke says.

Some larger providers, such as Level 3 or Williams, which is also about to enter the
clearinghouse business, could drive those applications. However, they too must wait on a
market that is just gearing up.

"I know some companies that are starting to work them, but they are not delivering
any software until this year sometime, and they still have to get tested and go through
beta deployments."

A Chink in the Wall

Despite the gloomy state of IP telephony standards, some steps are being taken to
introduce new ideas or take action to resolve the thorniest issues.

Despite its delays, the iNOW! effort shows progress, says Zwall. "iNOW! has
required certain action items that had to be part of that consortium. People actually had
to do something. They have come a long way. Not everyone is compliant, but it is a long
way from two years ago."

Gateway vendors weren’t against interoperability, "they were just not speeding
toward it," Evslin says. "Now they get it and are doing it at various

Beyond encouraging standardization, some are thinking about basic architecture changes
that could radically improve the entire mechanism by which IP telephony traffic is

These ideas, under discussion in the International Softswitch Consortium’s carrier
working group (, would put
exchange and interoperability in an entirely different part of the network.

There are two camps, "about how you architect how one network talks to
another," says Astoorian. The model today is for peer-to-peer relationships between
gateways all over the world, where gateways are able to talk to other gateways, no matter
what network they are in.

"It has efficiencies in network architecture, but creates problems in terms of
manageability," says Astoorian.

Elliott backs a different architecture, a voice network access point (NAP), a version
of today’s NAPs where IP traffic is exchange, but optimized for voice so delay is
minimized. Such a central exchange point would have two kinds of traffic: one for
interconnecting signaling and one for interconnecting the voice path.

"The reason to do it in a NAP is, if you have an independent party running a NAP,
they can publish rules about interconnection. That way it will not be oversubscribed, and
the NAP can be certified not to contribute to quality-of-service problems," Elliott

It also is assumed the networks joining a NAP are not connecting to the public
Internet, but are dedicated to voice over IP (VoIP), which would also improve QoS.

The NAP also would offer standards of measurement for metrics such as packet loss. And
the end points in each network would be able to detect packet loss, so the location of the
problem could be identified.

"If on a bilateral basis we exchange with, for example, Global Crossing (Ltd., we are both able to
measure, for the specific voice calls we set up with each other, the packet loss and the
latency, and compare with traffic exchange with other voice-over-IP gateways that we own
or other carriers," Elliott says. "We can detect if there are quality-of-service
problems with a specific carrier on a specific route, and we can get alarms. That is
really how you lick quality-of-service problems."

A component of such a NAP could be "a big media converter as an exchange point
from your network to another," says Astoorian. Such converters could eliminate
problems, such as incompatible gateways or compression algorithms. New gateways could be
introduced without having to change out a whole network.

Weber, who chairs a working group developing specifications for a voice NAP, says,
"Here is a single point where we can measure performance and there is a
network-to-network interface specifically for IP voice. In the circuit-switched world
there is a lot of knowledge of what a network interface is. Now we are trying to translate
that into the IP space."

Both models have pros and cons. With the NAP concept, there would be concerns about
introducing delay because so much bandwidth would pass through one location, though
limiting traffic and certifying delay would be one way around that. With a distributed
approach, a change in gateway technology would mean that every end point would have to be
changed out. Cost becomes an issue with features such as MPLS, which requires processing

"When you get below the IP layer and associated protocols, it adds a lot of cost
to those devices," Weber says. However, for NAPs, he points out, the tradeoffs are
potentially creating bottlenecks and scalability problems across networks."

Another approach is being developed by Concert Global Clearinghouse. It is working with
the existing infrastructure of IP telephony and clearinghouses to try to drive standards
among its member carriers or provide conversion where standards are not possible.

To overcome the problem of multiple incompatible gateways, "we have launched
support for multiple parallel platform," says King. "Many carriers already have
equipment, and, rather than saying you have to swap it all out, we have developed a
support capability for pools of networks that don’t interoperate."

Concert currently supports gateways by Cisco, Clarent, Lucent, NetCentric Corp. ( and VocalTec, the leading

Its AT&T heritage made Concert Global Clearinghouse an old hand with settlement

"We established software to enable us to harvest the call detail records from the
originating member and terminating member for each call," says King. "We have
learned that even if the call detail records don’t exactly match, certain components have
to be there, such as the originating network’s ID," the critical piece of information
for billing for the call.

"You would be surprised how many equipment vendors have not implemented an
originating ID in their call detail record format."

Concert also supports a new technology from Cisco, the Open Settlement Protocol (OSP),
which would enable calls to identify themselves to terminating gateways and effect
settlement automatically.

Beyond helping to translate among existing interoperable equipment, Concert has been
pushing interoperability under the H.323 protocol for call control among its member
carriers. "Many of the platform partners that we support today are of like
mind," King says.

She works directly with vendors on their next generation of product. When a company has
product ready, Concert dispatches teams to do integration testing. King expects that
gateways that meet Concert specifications may be available in the second quarter, with OSP
capability by late 2000.

"When calls happen from gateway to gateway we match call records and perform

Leave a comment

Your email address will not be published. Required fields are marked *

The ID is: 68396