Last month, I described the tribulations I endured while trying to establish an ISDN connection in the small office/home office (SOHO) lab I maintain at home. I wanted to have the ISDN line installed so that I could connect my SOHO lab to the Windows NT Magazine Lab, which already had an ISDN Basic Rate Interface (BRI) line. Using this connection, I planned to examine many issues associated with remote branch office and SOHO connectivity.
However, US West has still not activated my home ISDN line. This month, I decided to try to configure the Lab's ISDN connection for X2 (up to 56 kilobits per second--Kbps) access, hoping to achieve higher-speed connections than my 28.8Kbps modem provides.
Defining the Connection
I'll bet you're wondering why I chose X2 instead of K56Flex technology. I wanted a Lab connection that would work well with Remote Access Service (RAS), support ISDN BRI (128Kbps) connections, support standard V.34 (or slower) analog connections, and support 56Kbps connections. When I reviewed my options, the 3Com/U.S. Robotics Courier I-modem appeared to be ideal; it met all my criteria. The fact that the I-modem uses X2 to obtain 56Kbps connections was incidental.
After deciding on X2 connectivity, I did what I always do when I approach a new ISDN implementation: I called my buddy Mel, who owns and operates an Internet Service Provider (ISP) based solely on ISDN and frame relay technology. When I told him my plan, Mel's first words were, "You're nuts to implement a modem-based solution. It'll limit you to the maximum rate of the serial interface on the server (115Kbps), not the maximum BRI rate (128Kbps). You'd be much better off with a LAN-attached solution."
I fully understood Mel's concerns, but his advice didn't take into account everything I wanted my I-modem to enable me to do. I wanted my connection to support NetBEUI and IPX. Most LAN-attached solutions for ISDN access are TCP/IP-based, which would seriously limit the software I could test between the Lab and my SOHO lab.
Still, I contacted 3Com/U.S. Robotics, which also offers a family of LAN-attached servers. The company's smallest unit, NETServer, includes integrated I-modems, supports multiple protocols, works well with RAS, and can attach to my Ethernet network. However, the smallest NETServer supports eight BRI connections. The Lab has only one BRI connection. The NETServer struck me as overkill, and I decided I was better off relinquishing the 13Kbps difference between the 128Kbps BRI speed and 115Kbps serial speed. Besides, using a standalone I-modem is much simpler than setting up a LAN-attached solution. You attach the I-modem to your RAS server as you would attach any other modem. The Windows NT driver database comes with support for the I-modem.
So, I set my course of action. I decided to ignore Mel's advice and go with a standalone I-modem that would attach to one of the RAS servers in the Lab.
Fighting the Current
The Lab Guys had been using the Lab's ISDN line for a special Web project, so I knew the line was fully functional. I figured hooking up the I-modem would be easy. I would just disconnect the RJ-45 connector from the Web server and connect it to my I-modem, and the ISDN connection would automatically work. You'd think that 20 years of network consulting experience would have taught me to be a little less optimistic.
Physically connecting the I-modem to my ISDN line and RAS server was simple. Verifying that the I-modem was using the latest internal (flash) code was easy. Installing the I-modem configuration software was a piece of cake. Even configuring RAS to support the I-modem was a walk in the park. But convincing the I-modem and the ISDN line to cooperate was an entirely different matter.
The first set of problems I encountered involved the I-modem configuration software. This software configures such ISDN settings as the BRI line's two Service Profile Identifiers (SPIDs) and the type of telco switch on the other end of the line. Screen 1 shows the main configuration screen. You can also configure the ISDN settings by using a terminal program to connect to the I-modem and issuing AT commands, but that option seemed a little barbaric. The I-modem configuration software theoretically makes configuration easy because it collects the information it needs from you, downloads that information to the modem, and issues the AT commands for you.
But I had trouble getting the I-modem configuration software to download the correct values. I kept getting write errors when the software downloaded the data. Sometimes the software gave me an error message and failed to set the values. Sometimes I got an error message, but the software set the correct values anyway. Decidedly, 3Com/U.S. Robotics needs to work on this configuration software.
When I finally succeeded in configuring the ISDN settings, I took advantage of a feature of the configuration software that tests the end-to-end connection between the I-modem and the telco switch. The first time I ran the test, it reported that my end-to-end link had problems. Screen 2 shows the error message I grew to hate.
After finding out that my connection did not work, I tried many different combinations of parameters in an effort to resolve the problem. Of course, the unreliable nature of the configuration software complicated this experimentation. I had to spend extra time reloading the software and reconfiguring its parameters to get around the write errors I kept getting.
Despite the effort I put into establishing this connection, I was unable to find any combination of parameters that led to a successful link. Or so I thought.
Good News, Bad News
Finally, I broke down and called 3Com/U.S. Robotics technical support. A representative told me that the configuration program was useless and that I should connect directly to the modem through HyperTerminal and use the AT commands. When I asked about the test results, the representative told me not to believe what I saw. The test results are frequently false, the representative said, and as long as the light-emitting diodes (LEDs) on the I-modem don't indicate a problem, the connection is OK. The company really needs to work on this configuration software.
When I got off the phone with 3Com/U.S. Robotics, I immediately called the I-modem data channel, hoping to hear the familiar squelching of modem negotiation. Instead I heard a fast busy signal. I wanted to give the I-modem the benefit of the doubt, so I hooked the unit up to a phone and called the analog channel. Again the I-modem rewarded me with a fast busy signal.
At that point, the blood rushed out of my face, and a chill shot up my spine. The fast busy signal could only mean that the ISDN line wasn't provisioned to accept analog calls and that I would have to get US West to correct the problem.
I called Mel, who not only confirmed my suspicion, but made me feel even worse by adding, "I don't know of any case where a phone company has reprovisioned an ISDN line correctly. You might be better off having US West disconnect the line and add a new one." That was not what I wanted to hear.
Because of my horrible experience trying to get US West to provide ISDN service to my SOHO lab, I referred the problem to my company's telephony administrator. The building has many circuits (ISDN and otherwise), so I hoped the administrator would have better leverage with US West than I do.
I got very, very lucky. First, US West confirmed that my BRI circuit was not provisioned for analog calls. The provisioning was fine for the Web application the Lab originally used the line for, but to link to my SOHO lab, I needed to dial in using X2 and V.34 modems over analog lines. Second, US West reprovisioned the line correctly within a couple weeks of my request. I was skeptical when the telephony administrator told me US West had made the change. But when I dialed in to the I-modem over an analog line and heard the answering squelch ... well, I had an almost-religious experience.
When I had resolved the I-modem configuration issues and the ISDN provisioning, I was ready to rush home to my SOHO lab and dial in using X2. Was my SOHO connection to the Lab successful? You'll have to read next month's Lab Guys column to find out. In the meantime, if you happen to bump into any US West representatives, you can let them know I'm still waiting to hear why I don't yet have an ISDN connection in my SOHO lab. They can call anytime.
