ISDN's Last Stand

It would seem that every technology pundit eventually gets around to complaining about their ISDN experience. Like end-of-year wrap-ups, columns on ISDN seem to be an unavoidable part of the gig. I swore I wouldn't do one. I figured, hey, everything's been said. But then [dim lights; play rolling thunder sounds], I had my area code split [flash and crash of lightning].

Although PacBell had been talking about splitting the San Francisco peninsula off of 415 into 650, they didn't tell their ISDN customers exactly when it would happen. I found out when my dial-on-demand Internet router stopped working. After checking and double-checking the configs (unlike analog phones, you have to program your phone number into ISDN equipment. ), I changed the ISDN directory numbers and SPIDs to use the 650 area code. Still no joy. I called PacBell's ISDN help desk, and they said that although the numbers had indeed changed, the SPIDs had not. Nor would they. Ever.

Sure enough, after changing the SPID entries in my Pipeline P-75 back to their original settings, the network worked once again. Two weeks later, everything stopped, again. "Never," apparently, isn't such a long time, as my SPIDs had been changed to the new 650 area code, again without any advance warning. After a quick reconfig, I was back on-line.

Once was comical, maybe even amusing. Twice was downright annoying. I mean, c'mon!, this is the age of digital networking! Why am I even mucking around with phone numbers, SPIDs, and switch types in the first place? DHCP gives us self-configuring LAN equipment; why can't we have self-configuring digital telephony? We've got a D channel that's always on, so surely there must be a way to have a negotiated connection that allows for plug-n-play telecommunications as well?

Well, there isn't, but there will be soon. There are several technologies currently being worked on by BellCore and the equipment vendors that will provide this capability within the next couple of years. Most important, some of them even work.

But will it matter? Two or three years is a long time. ISDN has failed to hit mainstream status, despite a variety of benefits. ISDN seems to be permanently stuck in early-adopter mode.

Part of this is due to the technical configuration issues, making ISDN too difficult for your average man-on-the-street. Another part of this comes from the low price-performance horizon that ISDN carries. My monthly ISDN bill (including the ISP charges) is well over $400 per month. That's just too high for 128k of bandwidth (although my usage is very high, and probably exceeds ISDN's design objective).

Of these two problems, I believe that the issue of ISDN being hard-to-use is probably the more pressing. My mother installed a second voice line for her Internet connectivity rather than mess with the equipment and configuration issues surrounding ISDN. My guess is that she is more like the market than I am. There is a real, identifiable, justifiable need to make using ISDN a simple, plug-n-play experience.

Five Cards

To wit, there are five action areas that are promising a simplified ISDN experience. Some of these efforts are non-technical procedural changes, while others are radical departures from the ISDN standard that exists in the USA now.

Most of these efforts are addressing the issue of SPIDs (Service Profile Identifiers). For those of you who don't know about SPIDs, they provide certain call-handling and routing capabilities to the devices at a customer's location. It is important to note that SPIDs are unique to North America. Europe does not have SPIDs, and as a result they already have plug-n-play ISDN. However, they do not have the advanced call handling capabilities that we do. In order for them to do things like conferencing and the like, they must use a PBX or another intelligent system at their premise. We get this stuff from the switch essentially for free because of SPIDs.

SPIDs are indeed a nightmare (as I saw when I went through the area code split), but they are not the only issue. There are many, many technical areas of ISDN configuration that need to be addressed before it can be a plug-n-play type of solution. Currently, a user also has to identify the phone numbers in use, the make and model of switch in use in their neighborhood, and even whether or not a line is configured to accept voice, data, or both types of traffic. Until the need for these details is obviated, ISDN simply won't make it as a mainstream technology.

	SPID Simplification The most basic solution to the SPID configuration problem, called SPID Simplification, seeks to eliminate SPID configuration issues by ignoring them. Rather than have each switch vendor use their own SPID addressing schemes, SPID Simplification recommends that SPIDs should simply be the 10-digit telephone number, with "0101" tacked onto the end. This still requires a user to know their ISDN telephone numbers, and does not eliminate any of the other configuration parameters (such as the type of switch in use, etc.). All this does is eliminate the need for a user to enter the device's SPIDs during configuration. Nor does it work in all cases. For instance, during the two weeks where my telephone numbers were in one area code and my SPIDs were in another, any device that mandated the use of SPID Simplification would not have worked. Period. So while it is probably a good idea to standardize SPID formats, it is not a good idea to mandate the use of the SPID Simplification proposal. Luckily, none of the vendors I spoke to were requiring its use at this time, nor were they planning to in the future.
	Auto Switch ID Another proposal for simplifying the end-user experience came from VIA, the Vendor ISDN Association. As can be gathered by the TLA, VIA is a consortium of end-user ISDN equipment (and interested parties) whose membership includes firms such as Cisco, 3Com and Ascend, along with a handful of Internet Service Providers and end-users. VIA's charter is to make ISDN's use as a data service more viable. To this extent, they promoted a suite of enhancements called the Initialization Simplification Initiative (ISI). Part of this proposal involved establishing a standard mechanism for determining the switch type and software version in use on a user's circuit. By providing a way to automatically detect the switch in use, customers will not have to enter this information by hand. It's interesting to note that some vendors don't even bother determining what type of switch is in use. For example, the folks at JetStream, makers of the popular Front Desk call management product don't care what switch is in use. Instead they rely on their customers being behind an NI1-compliant switch, as their product will not function otherwise. What about those people who aren't on an NI1-compliant switch? Then they're "not a customer," according to the JetStream people I talked to. Most of the switches deployed across the US are NI1-compliant, so they feel that this is an acceptable trade-off. They're having a good deal of success, so perhaps they're right.
	Auto SPID Another part of the ISI initiative, and one that is much more useful, is a protocol similar to AutoSwitch that automatically determines the primary SPID in use on the circuit. According to the VIA documentation, "AutoSPID is a feature which allows the central office switch to detect the Service Profile Identifier (SPID) automatically, eliminating the need for the end user to manually enter the information upon initialization of the ISDN line." Essentially, whenever an end-user device is powered on, it asks the switch for the SPID associated with that circuit, and the switch is supposed to respond accordingly. Now this is useful, and it would have worked in my scenario, assuming PacBell were to reinitialize the circuit when the SPIDs were changed. However, like Switch ID, this only provides one piece of information (albeit crucial, as we will see in a moment). Further, the technology isn't here in a widely-usable form as of yet. Although Lucent and Siemens both support AutoSPID now, Northern Telecom does not (guess which one I'm on). Also, the standard implementation of AutoSPID is only now being tested in some preliminary market trials, with end-user equipment vendors starting to design it into their next revs. Don't look for this technology to hit mainstream implementations until the end of this year at the earliest. Some vendors (such as Ascend and Cisco) provide hard-coded mechanisms for automatically determining the SPIDs in use, with varying levels of success. Ascend's "AutoSPID" and Cisco's "Autodetection" both attempt to determine the SPID based on the switch and phone numbers in use. They then test against a variety of combinations, trying to find one that works on that circuit. It's important to note that these mechanisms would most definitely not have worked in a situation such as the one that I faced. However, both Ascend and Cisco have expressed interest in AutoSPID, with the latter promising support for it later this year.
	Parameter Downloading Each of the proposals itemized above only provide fine-point, limited solutions to the overall problem of configuring ISDN equipment. Recognizing the limited nature of these solutions, a proposal for a technology called Parameter Downloading is currently making the rounds that hopes to alleviate the problem entirely. Parameter Downloading is conceptually similar to DHCP in that an ISDN device can simply ask the switch for all of its configuration information when it is powered on. However, also like DHCP, in order to receive the appropriate information, the requesting device must ask for it by name, meaning at least one unique identifier is still required. That identifier happens to be a SPID. Yes, that's right, in order for the device to get its configuration information it has to know at least part of it in advance. Although switches are certainly able to determine the profile in use, this is not part of the Parameter Downloading specification. This is why AutoSPID is so important. By utilizing AutoSPID, a device can find the primary SPID for the circuit it occupies, and then turn around and issue a Parameter Download request back to the switch, gathering all of the phone numbers, secondary SPIDs, switch type, and even call-handling capabilities such as conferencing and caller ID. Once this information is retrieved, the device is fully operational. By combining Auto SPID with Parameter Downloading, a user only has to plug in the ISDN equipment and power it on. Anytime a change is made to the line provisioning, the telco can simply drop the circuit, and the device will reconfigure itself when it is reactivated. Now the bad news: only 2 of the switch vendors currently support it, and none of the router manufacturers I spoke to have working code. The standard itself won't even be finalized until sometime this year. Even then, the telcos will have to install new software onto their networks, which will take another year or so. Don't look for this functionality to be widely available until 1999 or 2000. Ugh.
	Non-Initializing Terminals All this just to get around SPIDs? What about totally eliminating the problem and using dumb equipment like our cousins in Europe? This has been proposed in the form of a technology called Non-Initializing Terminals (NITs). Essentially, there is no intelligent profile, and the device doesn't have any smarts, either. Rather, they simply allocate a circuit whenever a call is made. However, since it doesn't allow for advanced call management features like conferencing, none of the vendors who implement voice-specific features are too thrilled with the proposal. Meanwhile, the telcos, who make money by selling advanced features over ISDN, would have to manage a naked specification along with a rich one. They aren't jumping for joy either. My take: I wouldn't plan on ever seeing NIT take off, except maybe in the dumbest of ISDN modems, and only in the richest of calling areas.

Too Little, Too Late?

These enhancements are all great news, but are probably too long in coming. Although Parameter Downloading would make using ISDN as easy as using analog phone service (in theory anway), it isn't going to be widely available for at least two years, and probably for three. Even then it will still be a read-only specification. What's really needed is a bi-directional negotiation protocol that allows the equipment to tell the switch what features it wants. This is going to be even longer in coming, since the telcos, who charge on a per-feature basis, probably won't let equipment and users add/delete features on an ad-hoc basis for a long, long time.

Regardless, even just looking at the two year window we see that there is a serious threat to ISDN's acceptance as a mainstream technology on the lines of analog service and cable television. By this time, cable modems, data-over-power grid, satellite and xDSL will likely have significant infrastructures in place, and will have proven (or disproven) themselves as reliable alternatives to telco-based communication technologies.

If, within that two or three years, any one of these competing technologies offer better price/performance and are easier to configure, then ISDN will fail to become as pervasive as it could have. Let's face it: ISDN just hasn't hit mainstream status. The only people I know who use it are professionals who can comfortably be classed into the technology-enthusiast or early-adopter markets. Telecommuters are the driving factor in the latest wave of buyers, but they're not choosing this solution; rather, it is being chosen for them by an early-adopter at their office, and only because there are no viable alternatives.

This is changing. My brother in Tennessee is enthusiastically ordering high-speed cable modem service, and for a measly $40-a-month, flat. A friend near me here in Northern California is playing with DirecPC and loving every minute of it. These technologies are real, offering better price/performance, and better ease-of-use. Over the next two or three years, they will only become more viable, taking more opportunities away from ISDN.

Having said all that however, the one key benefit that ISDN has over these other technologies is the unique ability to deliver high-quality telephony services as well as data. Advanced call management features such as those found in ISDN provide users with Jetson-esque PBX capabilities from home, using the intelligent switching fabric. Cable modems, satellite, data-over-power-grid and other high-speed data services don't offer any voice capabilities at all.

However, even this may change. With the advent of bigger pipes and better encryption, voice-over-IP may be a realistic alternative to telco voice services inside of two years. This is the biggest concern to the RBOCS: If these data networks are able to provide low-cost voice services, then what advantage is there to using the telco's network at all?

This is probably why the telcos are pushing the FCC to revisit per-minute charges for data service providers. Although defeated once when the FCC "tentatively concluded that providers of information services (including Internet service providers) should not be subject to the interstate access charges that local telephone companies currently assess on long-distance carriers," the subject is coming up for discussion again.

Perhaps rather than try to make competing technologies expensive, providers should work to make ISDN (and other services like fractional-T1) cheaper. That combined with ease-of-use would help to boost ISDN's acceptance in a larger mainstream market. Oh, and it needs to be done this year, not sometime in the next millennium.

What do you think?

As always, feel free to contact me if you have any questions or comments.

Eric A. Hall
Chief Bottle Washer, EHS Company

Written by Eric A. Hall.
Copyright © 1998, EHS Company. net.Opinion is a trademark of EHS Company. All rights reserved.