VOIP: Stalled at the Demarc
Volume 29, Number 4
April 1999, pp. 12-14
By Tom Nolle, president of CIMI Corp., a consulting firm that specializes in advanced computer and communications networks,
and a member of the BCR Board of Contributors.
The following is the full text of the printed article:
A lot has been written about the concept of voice over IP (VOIP). New service providers like Qwest and
Level 3 have, to a degree, based their business propositions on it, and VOIP has been hailed as the
vehicle to get us to Network Nirvana--convergence.
Most of the claims for VOIP, however, like those heralding the arrival of many other new technologies, are
either exaggerated or false. In five years VOIP will not have reshaped networking, nor is it likely to after
10 years.
The degree to which VOIP has any impact on networking is likely to depend on whether we are willing to
get over our fascination with overworked concepts like "convergence" and, instead, deal with real core
networking issues. A good place to start is the place where users and networks already "converge"--the
demarc.
The convergence debate has focused attention on whether IP can deliver quality voice services. In
technology terms, that means focusing on issues like delay management, compression, etc. Ironically, all
of this discussion centers on how to make VOIP equivalent to POTS.
But equivalence won't be enough. Think about it: Why should anyone displace current voice technology
for a new system that promises, at best, equivalent service, and carries a substantial risk of
less-than-equivalent service?
New networking technologies typically become successful because of their features. If service providers
expect buyers to see VOIP as something other than cheap long distance service, they've got to deliver
new features to users of traditional phones.
But what are VOIP's features, and what kinds of devices are required to attain them? Are the combined
benefits of the service features and devices compelling enough to motivate a buyer to switch from POTS?
VOIP's Unique Features?
Let's get real here. The LECs earn more money selling custom-calling features than all carriers--IXCs,
LECs, ISPs, CLECs, DLECs and anyone else you can think of--earn selling frame relay services. That's
pretty solid evidence that telephony doesn't need IP to incorporate special features. However, the
question of the day is whether even more services could be delivered via an IP-based network.
The buyers we've talked to and surveyed think that the answer is yes. Slightly more than half believe
that an IP-based voice network could offer more features than a traditional voice network. There are
sound reasons behind that position.
Telephone switching is increasingly a software game, and the software used in large switches is incredibly
complex. Most switch vendors spend years developing and testing their new software "versions"--aka
"generics." Obviously, all this testing and development means that it takes a long time for new features to
be introduced.
Contrast this with the client/server computing model, particularly the "browser" model of Web
applications. Applications are easily created using structured high-level languages (HTML, Java), and can
consist of user-authored elements, as well as elements developed by equipment vendors, software
vendors or integrators.
The hyperlink nature of the software tends to isolate elements from one another, so changes or additions
in one area don't threaten others. Development cycles for even complex multimedia Web content are
measured in weeks, not years. There are also more programmers skilled in developing for the
data-oriented client/server model.
While in theory we could apply data-oriented programming practices to develop SS7-based features, in
the real world that's not going to happen. The problem is the interface between the user and the
switched telephone network--the thing telephony experts refer to as the "call model." You interact with a
call model when you dial your phone; it's what decides that *69 is a feature request and not a called
phone number. Unfortunately, changes to features in the voice network often require changes to the call
model, so the provision of "back-office" telephony features via IP data applications is likely to stall.
Here's an example. Suppose you want to offer a telephony feature that lets you determine whether a
given phone number is supported by a POTS or IP-based interface. Perhaps you'd dial *1 and then the
number you want to check. The problem is that a switch using the current call model wouldn't know to
collect the digits in that kind of sequence. The method used to activate the feature would have to fit the
pattern of digit entry and decoding built into today's switches. A flexible call model would let carriers (or
even users) select the way their features were activated.
A New Demarc Device to the Rescue?
If we have to move the current call model out of the way to support new features, why not consider
using an IP-based approach? Our research indicates that corporate buyers would accept an IP-equipped
voice connection to the user if the demarc can accommodate standard instruments. Can the demarc play
this kind of role?
There are two data protocols proposed for use in IP telephony--H.323 and the Session Initiation Protocol
(SIP) under development in the IETF. Both provide features that are very similar to the features of
standard telephony--read: You can make calls--and both are at least as sophisticated as today's
telephony Touch-Tone pad interaction. Indeed, converting Touch-Tone dialing to H.323 sequences
already is an element in many current VOIP gateway products.
Therefore, all that's needed is to transfer that feature out of a gateway and into a demarc device. In
making this transfer, however, it will be essential to avoid creating a fixed relationship between
Touch-Tone sequences and H.323 or SIP calling messages. That would be equivalent to imposing a fixed
call model.
Instead, what's required is a policy management-based interface between the IP dialing language (H.323,
for example) and the Touch-Tone sequences. By changing the rules used to decode dial sequences, a
service provider or, for that matter, a user, could alter the "call model" and facilitate feature selection.
Coupled with a data-oriented feature creation architecture based on Web techniques, you'd be able to
create telephony features in days or weeks, not years.
Ahh, you say. But won't this get out of control? People already have a tough time remembering the dial
sequences used to invoke special calling features. If we added new ones, how long would it be before we
were all trying to remember whether to dial "*34*NNN-NNNN*70*" or whatever to invoke follow-me call
forwarding?
A New Role for Desktop PCs
Perhaps desktop PCs can come to the rescue. Our research shows that while only 5 percent of end users
want to use speakers and microphones on their desktop computers to make and receive calls, nearly 20
percent already use their PCs to assist them in some way to make phone calls. In short, while users reject
calling via computer, calling with the aid of a computer is much more popular.
That data suggests a range of possibilities for an IP-telephony demarc device:
Option 1: It could be used to support a network of IP-based computers, each of which is linked to a
local phone via an RJ-11 adapter and PC interface card. With minor modifications, modem adapters could
be employed for this task. The PC would then act as the controller for the phone, adding screen dialing
commands, virtual "feature buttons" to represent all those complex dial sequences, and integration with
popular contact software packages for autodialing.
Option 2: It could be used to support a network of computers and a parallel network of traditional
phones. The phone connections would be terminated in the IP demarc device rather than at the desktop
computer, and a policy database would link each extension number to a desktop PC linked to the same IP
demarc via LAN connection.
Option 3: It could be used to support customized, IP-based phones, with or without an assist from
each phone user's desktop computer.
It is also clear that at least some of the features of this smart IP voice demarc could be offloaded and
pushed to the desktop computer. The "call model" would then run on the PC, with the IP demarc device
providing little more than support for the collective functions of directory management needed to provide
internal calling.
Conclusion
Other models might evolve, unless VOIP is crushed by its own weight. The greatest threat to VOIP is all
the hype that surrounds it. Like other technologies--ATM, push technology and IP switching--an excess
of enthusiasm often actually deters adoption, because no one takes the time to address the real
questions and the difficult implementation issues.
Apparently, equipment vendors and service providers are convinced that buyers "want" VOIP so much
that they don't think they have to make specific commitments regarding feature sets or the integration of
services with premises equipment. Very little time and/or money has gone into developing features.
But voice-over-IP won't amount to anything other than network plumbing unless special features are
developed for it. Once the features exist, VOIP can become a viable service, but then it will require a
device to provide the critical user-to-network connection; think DSU/CSUs, think FRADs.
The missing link in the VOIP debate involves the nature of the demarc. Until that issue gets resolved,
there won't be any real momentum in the VOIP market.
===============
but then some people said, voice will be free over data in two years; seems like in a dream world; no way it can happen in many countries where voice calls are heavily regulated by PTT and goverments. Even VOIP is a long long way to go based on the above article; free voice is a joke! all imo. |
