WAN Testing
Siemens developed and made open an ISDN protocol named CorNet which enabled fully feature transparent ISDN wide area networks over conventional T1 circuits. The announcement stirred considerable excitement since public PRI protocol based on ITU-T Q921 and Q931 recommendations was not yet available.
A directive went out that verification of CorNet should be done in a mixed WAN comprising the entire Siemens and Rolm family of PBX's. What this meant was that we had to verify feature transparency amongst PBX's that were never originally intended to network with each other.
While our Hicom lab was having Rolm 9751 series PBX's and Siemens 9200's added into our test areas, we were busy writing testplans for the new mixed network. The main challenge was quickly learning how features we were accustomed to on our own switch worked on these other switches.
Because phones, terminals and other devices were different from those we were accustomed to, feature invocations, displays and tones could be expected to differ amongst phone types and we had to know what to expect. How to recognize error messages on the administration terminals as well as detect when these switches were resetting or in alarm is also something we had to rapidly familiarize ourselves with. Network synchronization was also of some concern. Normally, local experts are available to consult with. In this case, no local experts were available since the switches were brought in from other design centers.
Once testing began, unforseen challenges emerged. One was that most testing needs to be done in a degree of isolation. Each lab area had multiple Hicom switches networked to a single new 9200 and 9751. The problem here being, when multiple independent scenarios are taking place on a switch, knowing who, or what caused the the problem you just encountered was always difficult to determine, especially if you couldn't immediately reproduce the scenario.
At any given moment when you were trying to conduct a test involving a Hicom, a 9200, or 9751, other testers independantly from you might be using the same 9200 or 9751 to originate a call, terminate a call or transit a call through. Many errors detected on the 9200 and 9751 simply went unreported due to being unreproducible.
Using a protocol analyzer to simultaneously monitor messaging was near impossible in the traditional manner we used them. This being due to the unrelated traffic. Fortunately, I was able to figure out how to set the protocol analyzer to log messaging only for a specific call reference value.
While a test engineers job is to verify product conformance to requirements, no one wanted to spend much time attempting to reproduce an error if they didn't first have a degree of confidence that something they did is what caused the error.
Another problem was that we were to write up scenarios thought to originate with these other switches and send them to a local official contact who would forward them to the remote official contact. The process appeared to be a black hole. Things went in but never returned. Conversely, when one of us was handed an issue reported by a counterpart in a 9200 lab or 9751 lab, we commonly reported back to our local contact the scenario could either not be reproduced, or was a known error.
Ultimately, the concept of corporate mixed network WANs via CorNet never caught on in a significant way. One major reason being, CorNet equiped equipment suffered delays to market thereby allowing ISDN PRI, BRI and the SS7 ISUP to become standardized and negate CorNet's first mover advantage.
