VocalNet, a powerful yet easily configured telephony gateway, will
further a revolution sweeping the telecommunications field. More specifically,
VocalNet bridges the gap between the telephone and data networks. To create such a
bridge, you need two gateways. The first gateway allows voice to enter the IP realm by
converting voice to data, compressing it, packetizing it, and sending it to the second
gateway, which reconstructs the voice and forwards it to the telephone network.
At CTI, were well acquainted with several of the IP gateways now
hitting the market. For example, in the last issue, we covered Micoms V/IP Phone/Fax
IP gateway. In addition, we sponsored the IP Telephony Hotspot at the CommUnity show
(co-located with NetWorld + Interop) in Atlanta, Georgia. This Hot Spot included several
prominent companies showcasing their telephony gateway systems. As impressive as this
group was, we suppose it represents but a small fraction of the gateways that will soon
inundate us. For vendors, the incentive providing a way to circumvent longdistance
charges is simply irresistable.
Inter-Tel, the vendor were focusing on in this review, has built its
VocalNet gateway product on Natural MicroSystems AG Access and Fusion
development products, adding its own software layer to provide effortless setup,
configuration, and management. AG Access provides the APIs for the Windows NT environment
to support the Alliance Generation family of boards; Fusion is the PC development platform
for standards-based IP Telephony gateways.
Originally, the two VocalNet telephony gateways we received were turnkey systems
built using HewlettPackard PCs with T1 interfaces. However, we wanted to build our own
gateways. Also, we preferred working with POTS lines. So, we returned the gateways and
asked Inter-Tel to send the components that would let us build two 8-line VocalNet
telephony gateways. Each gateway consisted of the following components:
- An AG-8 (Alliance Generation) card supporting 8 analog interfaces.
- An AG-DSP/RT to support vocoder and echo cancellation algorithms.
- A TX2000 Network Interface Card to interface the PC to the network.
- Necessary software drivers and applications.
For one of the gateways, we used the Crystal CS1000 industrial PC (donated to CTI labs
through the CTI Benefactors program). This is a 200MHz Pentium PC with 64 Megabytes RAM
running Windows NT Workstation 4.0. For our other gateway, we used a generic PC with a 200
MHz Pentium and 32 Megabytes of RAM running Windows NT Server 4.0.
Although we set up both telephony gateways in our LAN, for the purposes of our tests,
they could have been far apart on a WAN. To make this point clearer to ourselves, we
labeled the Crystal PC Los Angeles and the other one New York. Our
plan was to call into the New York gateway and have our call routed to the Los Angeles
gateway and finally to the specific phone number to which we wanted to be connected. We
followed the same installation process for both PCs (except that we assigned them
different TCP/IP addresses). Thus, for our purposes, the two gateways were identical.
Using the manual as our guide, we inspected all the boards for correct memory
address and IRQ configurations. The VocalNet manual explained that the default
settings on the cards specifically reference the Hewlett-Packard Net server E series
(VocalNets recommended platform). We assumed the same settings would work on
our PCs, and we hoped for the best (with the understanding that if the system failed we
could not blame VocalNet!). We installed the AG-8 card followed by the TX2000
network interface card and finally the AG-DSP/RT card. Then we connected the cards
together using the MVIP bus connector ribbon. We then connected the TX2000 to our 10Base-T
LAN hub and then plugged in the requisite security key (HASP) to the PCs parallel
The VocalNet software consisted of eleven 1.44-Megabyte diskettes, nine of
which were Natural MicroSystemsrelated drivers and tools. These included AG Access,
Fusion, and drivers for the AG and the TX2000 boards. The other two diskettes contained
the VocalNet server software, which contained modules for running, configuring, and
managing the gateways. Altogether, the software installation for VocalNet consisted
of six setup programs plus the network card driver installation. (We wish that InterTel
would replace the diskettes with a CDROM and combine the several setup programs into one.)
We started the software setup process by sequentially installing the various drivers
and utilities contained in the VocalNet diskettes. We used diskette 8 to install the
driver for the TX2000 network interface card and followed it with diskette 9, which
contained the Fusion modules. At this point, we had installed all the basic software
components of the VocalNet system and were ready for the last piece, the
VocalNet server software.
We launched the setup program for the server software and were prompted to select from
- the database programming application, which locally or remotely defines routing and
other parameters for the telephony gateway.
- the monitor application, which locally or remotely monitors and logs the gateways
- the server module, which runs the VocalNet gateway.
We selected all the modules and continued with the setup program.
We finished up by installing the files pertaining to the security key (HASP). We ran
one of these files (labeled haspread.exe) to verify that the security key was
installed correctly, and that it could be accessed by VocalNet. We would like to
compliment VocalNet for its smooth setup process. The VocalNet telephony
gateway impressed us as a complex system, and we wondered how difficult the installation
could be. However, VocalNet, with the simplicity and ease of its installation,
relieved us of all our concerns.
The VocalNet telephony gateways well-organized Installation and Field
Maintenance Manual proved very helpful during setup and configuration. The manual
presented an overview; specifications and installations for digital T1, analog WTI-8, and
analog AG-8 boards; telephone system setup instructions; and sections on programming,
monitoring, and troubleshooting.
VocalNets online help facility was complete and available from just about
all screens. Context-sensitive help was also available, which made the software more
robust and easier to use. Although we found the help screen adequate, we would like to see
more details and samples in the help screens.
VocalNet is a standalone Internet telephony gateway server designed to integrate
with telephone systems that support standard telecom interfaces. It has the following
- T1, E1, ISDN PRI, and analog telephone support.
- Built on Natural MicroSystems AG Access and Fusion.
- Runs on Windows NT 4.0 Server or Workstation.
- Database and Monitor applications to configure and monitor the telephony gateway.
- Real-time, full-duplex voice communications over the Internet.
- Available in multiple port sizes.
- Can be operated using ordinary telephone sets.
- Onboard DSPs used for the compression or packetization of information, relieving the
After connecting both the New York and the Los Angeles servers to our LAN hub, we verified
network access by using the Windows Explorer from both telephony gateways to successfully
browse our network. Then, on the New York gateway, we started the VocalNet Database
Program, which let us configure and manage the VocalNet telephony gateway.
From the toolbar, we clicked on the IP Address List button to create a list of
our gateways names and IP addresses. The List of Server IP Addresses window is used
to enter the Internet Protocol (IP) addresses of all the VocalNet Servers with which
you wish to communicate. We used the New button to add our New York and Los Angeles
gateways to this list. After verifying that we had entered both gateways, we selected the
Network Load button from the toolbar to connect to our gateways database. The
VocalNet Database Program is a client/server-compatible application which allows the
administrator to connect to any VocalNet telephony gateway on the network including
the local gateway.
From the Connect-to-Server screen, we entered the New York servers IP
address in the Address field and clicked on Connect. We were connected to the New York
servers database and could now configure this gateway. Each gateways database
consists of five tables which set the routing and operational procedures for the gateway
to follow. These tables cover PSTN-toIP Routing, IP-to-PSTN Routing, Wildcard Character,
Miscellaneous Options, and Account Codes. These tables can be accessed from either the
Tables menu or the toolbar.
PSTN-to-IP: The first table we populated was the PSTN-to-IP routing table,
which is used to set up remote IP addresses for the telephone numbers received from the
attached telephone system or a direct caller. This table routes the calls based on
patternmatching rules, working its way from the top of the list to bottom. When a dial
pattern is matched to the dialed number, the call is then routed to the corresponding
gateway basically a translation procedure. The pattern-matching algorithms can be
as simple or as complex as one would need them to be; however, they need to be designed
carefully to correctly route the calls.
Also, the PSTN-to-IP table algorithms are used to modify the dialed numbers to
correctly instruct the receiving telephony gateway to connect the call. For example, it
may be necessary to strip off the first 1 or 0 from a dialed number before passing it on
to the receiving gateway. If the dialed number cannot be matched to any entries in the
table, VocalNet notifies the caller that the number is invalid and prompts the
caller to enter a valid number.
IP-to-PSTN: The IP-to-PSTN routing table is used by the receiving gateway to connect
the incoming call received from the Internet/Intranet to its destination. For example, the
VocalNet Server could instruct the attached telephone system to dial an extension
number or to select an outside line and dial a local telephone number.
Here, the same type of pattern matching is used to complete the calls. The incoming
numbers are matched to the Dial Pattern fields in the IP-toPSTN table working from the top
of the list to bottom. When a match is found, the corresponding Dial Rule is used to call
the number. Depending on the incoming number, the Dial Rule could signify just an
extension number (for example, if a PBX or Centrex service is attached to the gateway) or
a local number. We successfully entered a few simple entries in both the PSTN-to-IP and
the IP-to-PSTN tables. However, we could see how the pattern-matching entries could become
more complex as routing requirements get more specific. The good news is that in most
cases the pat-ternmatching rules will be simple and straightforward.
Wildcard: The Wildcard Character Table is used to set up the matching patterns for the
wildcard characters used in the PSTN-to-IP and IP-toPSTN routing tables. This table came
with a few default entries, and we did not add any new ones to it. The Wildcard table can
be especially useful for repetitive or complex patternmatching rules.
Miscellaneous Options and Account Codes: The Miscellaneous Options table changes some of the system parameters used to initialize or operate the VocalNet
server. These include the server access password, system prompts, various timers, and
hardware configuration options. The Account Codes Table is used to define account codes
that can be assigned to limit or measure call usage or to identify calls for billing.
Testing The System
We connected each gateway to an analog telephone (POTS) line and used a third
telephone set to call into the New York telephony gateway. Busy signal! We made several
more attempts and even rebooted the gateway, but we kept getting the busy signal. So, we
called Inter-Tels technical support department, which helped us identify the
The problem was that VocalNet by default expects a T1 board in the gateway, so
the system was initialized expecting a T1 interface. The solution was to set a couple of
parameters in the Miscellaneous options table for AG-8 board support and re-initialize the
system. These parameters were Hardware Configuration (which we set to AG8), Number of
DNIS/DID Digits Expected (which we set to 0), and Answer Interface (which we set to Enter
After making these changes on both systems (and using the Network Save button to save
the changes to the respective telephony gateways), we reinitialized the systems by
stopping and starting the vnet_srv service from the Services applet of the Control Panel.
Once again, we made a call into the New York gateway and heard a prompt instructing us to
enter a destination number of the party we wished to reach. We entered the number for
another phone in our labs, and we had connection.
At this point, our voice signal was traveling through the telephone network to the New
York gateway, being translated to IP packets and sent to the Los Angeles gateway over our
LAN, and traveling out to the telephone network and (finally) to our destination number.
We noticed some lag, which we attributed to the compression times. The voice quality,
while not crystal clear, was surprisingly good and echofree. Overall, we were very
impressed with VocalNets proficiency in reliably and efficiently transmitting
voice over IP.
Invoking the Monitor program from VocalNets application folder
launched the Monitors main window. This window is divided into two sections. The top
section displays the messages received from the connected VocalNet server; the
bottom section sends control messages to the connected gateway. This arrangement offers a
convenient place for administrators to conduct diagnostics and find bugs and
irregularities in the connected server.
We wanted to monitor the New York gateway, so we clicked the Connect-to-Server button,
which prompted us with a window to enter the servers address. After we entered the
New York gateways TCP/IP address, the monitor application connected to this server
and started to display its messages.
The Monitor application has a menu option to browse files on the connected server and
upload files to or delete files from the connected server (of course one can do these and
more using Windows Explorer). Another menu option allows the user to view a summary of
information about the connected server.
Another important menu item of the Monitor Program is the Options menu, which presents
a window where you can set some of the characteristics of the Monitor program. For
example, we used this window to define the name and size of the log file generated by
Finally, from the User Format tab, we selected the optional fields and filtering
options that the system would use when displaying the messages received from the connected
Vocal Net Server. We even selected the threads and modules we wanted to
ignore these messages. Beyond Our LAN We wanted to test VocalNet in a real-world
setting (beyond our LAN setup). Thus, we asked Inter-Tel to provide us with a connection
to their Inter-Tel.net gateway in Phoenix. From this gateway, we could make calls anywhere
within our state to gauge the quality of the product. To make a call, we dialed an 800
number followed by an extension, which took us to the Phoenix gateway. At the prompt, we
dialed our destination number within our state. The Phoenix gateway passed the number over
the WAN (using a dedicated bandwidth) to another gateway in New York City, which completed
the call by dialing the number.
The voice quality over the WAN was just as good as that within our LAN gateway setup.
We want to stress that telephony gateways such as the VocalNet are best used within
managed networks as opposed to the Internet since there can be a direct control over
bandwidth allocation and prioritization. Such control is not yet feasible on the Internet.
One of the essential requirements of any telephony gateway is its ability to
correctly pass through DTMF signals. VocalNet, which is unaffected by the codec
algorithms (it employs Microsofts GSM codec for voice transmission), performs this
task well. For example, VocalNet allows the caller to dial extension numbers when
the caller reaches a PBX.
Another VocalNet feature we liked was that it saved us the hassle of working with
AG configuration or other hardware initialization files. VocalNets database
program (the main administration application) was the only application necessary to set up
and configure the system.
We found VocalNets software applications to be user-friendly and practical,
although we felt that some of the features were a little obscure (for example, the
difference between Network Save and Local Save). With VocalNet, telephone sets
cannot be directly attached to the servers; however, the same effect can be achieved using
a PBX to interface the extensions to the VocalNet server. VocalNet is sold as
a turnkey system or as components to VARs, resellers, and endusers.
As a side note, Inter-Tel has launched its own long-distance service, Inter-Tel.net,
which uses a world-wide network of VocalNet Internet telephony gateways connected
over a dedicated bandwidth from large backbone providers.
VocalNet demonstrates that telephony gateways will become a significant force in the
telecommunications industry. Among the items we liked about VocalNet were ease of
setup, excellent software, great voice quality, and ease of use. We were also very
impressed by Inter-Tels knowledgeable technical support staff. These technicians
successfully guided us through several problems.
Some areas of improvement for VocalNet include RSVP and H.323 compliance and fax
support. In addition, the manual could be more userfriendly and detailed. All of these
items are, we are pleased to report, being addressed by Inter-Tel as it works toward
future releases of VocalNet. Also, Inter-Tel has plans to integrate CT Access,
Natural MicroSystems latest telephony development product, yielding a more powerful
and flexible telephony gateway.
We applaud Inter-Tel not only for the sound design and functionality of its
VocalNet gateway, but also for its contributions to the advancement of telephony
over the Internet/Intranet.