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.
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
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.
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
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
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
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
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
- 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
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.
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
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
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
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.