January 1999

Price: Call for pricing in your configuration.

Fusion 2.0 is Natural MicroSystem's latest development kit for Internet gateways. Building on the basic configuration of full T1 Internet telephony in two ISA boards, the new version offers enhancements in the underlying technology. The TX3000 board provides similar functionality to the TX200 with four to five times the performance. Starting with a 100 MHz PC with 32 MB of RAM running Windows NT 4.0 or greater, developers are able to create gateways with capacities from eight ports to multiple T1/E1s, fully integrated with PSTN interfaces. In addition to the vocoders supplied by Natural MicroSystems, gateways created using Fusion 2.0 are fully H.323 compliant, so that they will be interoperable with other Fusion-powered gateways. They will also have the ability to function with new algorithms that may surface.

INSTALLATION
We invited the people from Natural MicroSystems to come by TMC Labs and give us a demonstration of their product. The configuration they used for the demo contained two generic NMS Fusion-powered gateways, two analog phones, and two NetMeeting clients. A PC-PBX application designed specifically for the demo tied the pieces together and served as the PSTN. Our contacts ran through the demo, making phone-to-phone, phone-to-NetMeeting, and NetMeeting-to-NetMeeting calls.

After the demo, we built our own generic gateways using NMS boards that our contacts had brought with the demo. These included a TX3000 board, an AG-8 board, and an AG-T1 board. We attempted to build the gateway in a PC running Windows 95 that already had a version of Fusion installed on it from a previous gateway test that we had done in the labs. The earlier gateway was configured for a TX2000 board with prior versions of Fusion's vocoders.

Out first idea was simply to go into the configuration of the Fusion software and change the board settings to reflect a TX3000 board, insert some disks with H.323 and Fusion 2.0 patches, and then update the vocoders. However, we were not able to reach the desired outcome through this process, and began troubleshooting. When the dust cleared some time later, we realized that the previous installation of Fusion must have been customized, so that the code for the generic gateway we were building was not operating properly. To rectify the situation, we had to remove the prior installation and start from the beginning. We removed all the components of Fusion, then went through the process of installing all the components from our disks. When we finished, we tested the sample application that came with the gateway and then made a call using this application.

Finally, we repeated the process on a second PC, giving us two Fusion-powered gateways to test in the labs. Of course, this process wasn't quite as simple since we did not have our contacts from NMS watching over us. The first time we did this, we installed the software in the wrong order and ended up overwriting some of the demo application code with earlier versions. After consulting our contacts, we re-installed in the correct order and configured the demo application, thereby completing the setup.

DOCUMENTATION
Along with the NMS boards, we received an abundance (perhaps an overabundance) of Fusion literature. To fully illustrate the extent to which the documentation impressed us, we will briefly explain each document in the following section.

Perhaps the first manual we should introduce is the Fusion Installation Manual, which tells the user how to install, verify, and remove the software. Next, the Fusion Developer's Manual deals with a number of different topics including a discussion of the application architecture, and the Fusion API summary. In addition, this manual familiarizes the user with the PSTN Interface control and the Internet telephony interface control. It also features some important demonstration programs, specifically the AG-8, AG-T1/E1 and AG-T1/E1 ISDN programs, and discusses the sample gateway application that we used in the labs to test the functionality of the Fusion product. The Fusion AG TRAU Developer's Manual provides information for creating applications with the use of the AG TRAU (Transcoding and Rate Adapter Unit) service functions, events, and error codes. Rounding out this first division of manuals is the Host-Based Fusion Developer's Manual, targeted for programmers that develop Internet gateway applications. This guide is similar in structure to the previous two, dealing specifically with the HBF service.

After the installation of the Fusion software, the user will want to refer to the AG-T1 and AG-E1 Installation and Developer's Manual, which takes the user from the installation of the board through editing the AG Configuration file, to the verification of the installation. The remaining chapters in the manual deal with Trunk Channels and the AG Boards, and MVIP Connectivity. Documentation also consists of an AG Quad Installation and Developer's Manual, which goes through a similar scheme for the AG Quad board.

NMS has included a flood of documents dealing with the TXn000 Series of boards. The TX Series Hardware Installation Guide explains how to set up the memory address, interrupt request, jumper settings, V.24 and V.35 pod configuration, adapter cards and cabling, and specifications for both the TX2000 and TX3000 boards. This is followed by a much less extensive TX Series Software Installation Guide for Windows NT which provides simple steps for the installation of the TX software, as well as a troubleshooting guide for the TXn000 installation. The TX Series RTP/RTCP Developer's Guide is an important document that systematizes the architecture overview and references for the API, and function references for both the RTP and RTCP. Toward the end there is more sample code for developers to study.

The next group of manuals deals with AG Access and CT Access, both of which are robust APIs for developers to use. The CT Access Installation Manual and the AG Access Installation Manual inform the user how to install, verify, and remove the respective software components. One of the essential documents of the bunch is the CT Access Developer's Reference Manual. Just about everything in Fusion has CT Access lying underneath, so a good manual for the functions and the development environment is important for successful deployments. For users who have previously used other APIs for their application, the CT Access Migration Manual explains how to migrate to CT Access from ME/2/X, AG Access, MVIP-90, and SwitchPath.

Complementary to the CT Access manuals are the AG manuals. The first of these is the AG Runtime Configuration and Developer's Manual, which is a hearty and robust document covering the AG configuration file, agmon (the AG Loader/Monitor), and the configuration of the AG board DSP resources. This manual contains a glossary, AG board and driver error messages, sample configuration files, and utilities. This segment of manuals also includes a guide for the installation of Cool Edit 96, which is a simple two-page document that really did not deserve to be wrapped by itself. Akin to this manual is the AGM Library Developer's Reference Manual, which outlines the various operations performed by an application using the AGM library, and also explains how the functions relate to each other.

The Fusion H.323 Stack Programmer's Guide and Reference refers to what is perhaps the most important new feature of the NMS Fusion package. RADVision's H.323 Stack is a set of ITU H.323 compliant packages that provides the necessary tools for audio and video conferencing. This manual includes very specific information regarding syntax and technical specifications for the H.323 stack. Finally, there is another standalone manual, the Voice Message Service Developer's Reference Manual, which gives an overview of the CT Access Voice Message service and a reference to functions, errors and events.

In addition to the manuals discussed above, NMS includes the following with the Fusion package: Getting Started with MVIP Switching; Switching Service Developer's Reference Manual; the ADI Service Function Reference Manual; the T1/E1 Digital Trunk Monitor Service Developer's Reference Manual is a smaller manual dealing with the DTM service in a capacity similar to that of the ADI service manual; and the ADI Service Developer's Manual.

FEATURES
The Fusion 2.0 package consists of three hardware components and some software. Two of the hardware pieces are ISA slots, and the first of the hardware components is either an Alliance Generation T1 or E1 (AG-T1 or AG-E1), along with an AG Realtime/2 daughterboard. The AG-T1/E1 provides 24/30 ports of voice and fax processing with a full PSTN interface, including PRI ISDN, and an 8-port AG-8 is available for use in lower-capacity configurations. The AG Realtime/2 daughterboard attaches to the AG-T1/E1 and provides real-time vocoding for the ports on its motherboard. Using the MVIP bus, the AG-T1/E1 passes traffic to the third hardware component, a TX3000 board. The TX3000 board supports the integration of encoded speech with an Internet or LAN connection. A wide range of protocols are available from NMS for the TX3000, including SS7, X.25, TCP/IP, and SNA. The TX board converts encoded speech to IP packets, and supports IP routing and data protocols. It is available with a variety of data communications interfaces, including 10BaseT and 10Base2 Ethernet. All processing takes place on these boards, leaving the CPU free for higher level applications making the boards stackable for higher capacity systems.

Along with the hardware components, Fusion 2.0 also comes with a software development kit consisting of multiple APIs, including:

• A Telephony API under CT Access, for voice processing and gateway call control.
• A Switch Service API in CT Access for controlling the interface between telephony and IP network resources.
• An H.323 API for Internet telephony call control and establishing interoperability between different gateways.
• A Vocoder API, also in CT Access, for speech encoding.
• The TX Series Libraries, which include a Packet Network API for the control of IP network protocols.

CT Access standard features include telephony call control, voice record and playback, tone detection and generation, and MVIP and H.100 switching support. Prominent features of CT Access include:

• Natural Call Control including a simple call control API, network signaling protocols and control for physical interfaces.
• Call control primitive functions including digital signal detectors and generators, tone detectors and generators, LAPD access for ISDN, and timers for interfacing with proprietary switches or PBXs.
• Support for features such as DNIS/ANI and CallerID.
• Full-duplex voice play, record, and edit functions to simplify application development.
• The CT Access Prompt Builder for interactive voice response, based on the NMS VOX file format. This function accepts common interactive voice response strings such as dates, numbers, or monetary units, and converts them into a sequence of voice messages.
• Support for multiple voice-file formats, including .WAV and the NMS .VOX format.
• Syntrillium Software Corporation's CoolEdit96 graphical voice editor.
• Parameterized DSP algorithms and network signaling protocols, giving developers the ability to configure the application for any environment.

Fusion supplies multiple vocoders including the ITU G723.1 and G.729A algorithms, Microsoft GSM 6.10, the SX7300P/SX9600P vocoders from elemedia, and the Voxware MetaVoice RT24 algorithm. In addition, Fusion provides an open vocoder platform for porting of new emerging algorithms. Both the ITU G723.1 and G.729A algorithms and the MS GSM 6.10 are full-duplex implementations of the dual-rate vocoders with integrated echo cancellation. They also specify comfort noise generation during periods of silence.

The kit also includes a programmable jitter buffer that collects incoming packets and enables Fusion to rearrange the packets into the correct order to extrapolate lost packets. The size of the jitter buffer is configurable on a per channel basis, and can be used to control latency in real-time interactive voice conversations.

OPERATIONAL TESTING
The testing we performed on the Fusion product consisted of two separate portions. The first was a demonstration given by Natural MicroSystems in our conference room. Of course, the first thing that we inspected was the quality of speech, and the latency associated with a phone-to-phone call. It should be noted that all judgments made in the conference room were qualitative. The call was routed from one port on an AG-T1 to the same port on an AG-T1 board connected to the second gateway over a 10BaseT LAN connection through their sample application. Comparing the quality to gateways we had heard in the past, the NMS generic gateway seemed to have good speech quality, and the latency was also minimal. (Another thing to note here is that we had just finished our first part of the Gateway Shootout that appeared in the December issue, so latency and speech quality were still fresh in our recollections.)

After talking on this connection, we disconnected and made a call from one NetMeeting client to another. In this case, we noted that the speech quality and latency were noticeably worse. However, we were not disappointed with the call quality because the fact that we even had a call across NetMeeting clients without an Internet connection was intriguing enough. In addition, we knew that the H.323 compliance associated with Fusion could do more than a NetMeeting-to-NetMeeting call.

Soon after testing NetMeeting-to-NetMeeting quality, we asked to see a NetMeeting-to-phone connection. This took a couple of minutes, as the routing table for the PC-PBX needed to be updated for this new phone call. This entailed associating a phone number with the IP address of the NetMeeting client, so a phone could dial into the NetMeeting client though a simple dial string. We noticed that the quality of speech was fine on the end of the NetMeeting client, though it suffered at the other end. This pointed out to us that the speech coming from the NetMeeting client was more difficult to encode.

One other thing that we realized at this juncture was the unmistakable prospect for conducting conference calls over IP in a very simple, low-cost manner, because NetMeeting clients have multipoint conferencing already built in. Of course, this does not come as a revelation for the reader. However, with only one NetMeeting client and multiple phone sets, a conference can also be initiated. The NetMeeting client would of course be the host, and phone sets could be used to call in and connect to the conference.

The next step of course, was to build our own gateways and test them in the labs. We went through this process together for the first sample gateway, and finished off the pair over the phone as discussed in the installation section. As in the Gateway Shootout, we used our Hammer Testing unit to initiate calls and take test measurements. We had used the Hammer IT Prompt Test in the December '98 Gateway Shootout to measure the latency and speech quality scores. Another thing to note is that we had used the Hammer test on a gateway that had been built on the previous release of Fusion. Our tests showed that the latency had decreased about 25 percent from our earlier measurements to about 117.1 ms with the G723.1 algorithm and 177.5 ms with the GSM601 algorithm. The PSQM (Perceptual Speech Quality Measurement) scores also improved, though a direct comparison of scores was not possible. All we know is that lower is better, and the new version of Fusion produced lower PSQM scores.

Unfortunately, we had no way of testing the NetMeeting calls with our Hammer Testing unit. This was simply because we did not have a script that would initiate H.323 calls and to our knowledge, none has been developed by Hammer Technologies. We were not able to program a brand-new script in the time allotted for a review, so we had to regretfully pass on this portion. Hopefully, as H.323 compliant gateways become more prevalent, NetMeeting-to-NetMeeting and NetMeeting-to-phone scripts will become available. One more final note is that Hammer uses NMS board architecture to create the testing unit.

ROOM FOR IMPROVEMENT
The most interesting feature of Fusion 2.0 is also the aspect of Fusion that needs the most improvement. This, of course, is the H.323 stack and its functionality, since H.323 compliant gateways are only beginning to emerge, and this is a budding technology. Speech quality through a NetMeeting client is not as crisp or efficiently encoded, and this tells us that NMS needs to improve this technology before it becomes truly usable by the general public. Of course, we have no doubt that the H.323 stack will be improved as interoperable gateways become more popular.

Another aspect of the Fusion experience that we would like to see improved is the installation of the product. For now, upgrades from older versions of Fusion are executed using floppy disks, although we understand that plans to improve this process are already underway. We also had to edit the configuration files for the demo application with Notepad, and we would have preferred a user interface, although this type of design is usually left up to the developer. At any rate, we feel that it may be in Fusion's best interest if NMS produces a graphical interface for configuring their demo application. In this way, their developers will probably gain a better understanding of the overall structure.

CONCLUSION
Only a couple of months ago, we were beginning our Gateway Shootout and had received pairs of gateways from different companies. We joked and we dreamed about the gateways being interoperable, as this would make the IP network all that much more of a reality. The gateways we had covered a bunch of different compression algorithms, though they could not interoperate. We figured gateway manufacturers should make a point of being interoperable, and H.323 became the answer to our speculations. Soon thereafter, we attended the Natural MicroSystems Conference in San Francisco to learn that Fusion 2.0 had incorporated RADVision's H.323 stack. Now all we need to do is wait for the partners of NMS to develop these interoperable gateways and plug them into the IP backbone. We are looking forward to this imminent expansion.