NETWORK CROSSROADS / NOLLE
VOIP: Stalled at the Demarc
Volume 29, Number 4
April 1999, pp. 12-14
bcr.com
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.
---end---
Several other interesting articles in this month's BCR at: bcr.com |
