TMCnet - World's Largest Communications and Technology Community




November 1997


7300 West Boston Street
Chandler, AZ 85226-3224
Ph: 800-669-5858; Fx: 602-961-1370
Web site: www.inter-tel.com

Price: $2,000–4,500 per port.

Installation:  4.90
Documentation:  4.50
GUI:  4.70
Features:  4.70

Vocal’Net, a powerful yet easily configured telephony gateway, will further a revolution sweeping the telecommunications field. More specifically, Vocal’Net 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, we’re well acquainted with several of the IP gateways now hitting the market. For example, in the last issue, we covered Micom’s 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 we’re focusing on in this review, has built its Vocal’Net 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 Vocal’Net 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 Vocal’Net 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 Vocal’Net manual explained that the default settings on the cards specifically reference the Hewlett-Packard Net server E series (Vocal’Net’s 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 Vocal’Net!). 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 PC’s parallel port.

The Vocal’Net 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 Vocal’Net server software, which contained modules for running, configuring, and managing the gateways. Altogether, the software installation for Vocal’Net 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 Vocal’Net 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 Vocal’Net system and were ready for the last piece, the Vocal’Net server software.

We launched the setup program for the server software and were prompted to select from three modules:

  • 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 gateway’s activities.
  • the server module, which runs the Vocal’Net 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 Vocal’Net. We would like to compliment Vocal’Net for its smooth setup process. The Vocal’Net telephony gateway impressed us as a complex system, and we wondered how difficult the installation could be. However, Vocal’Net, with the simplicity and ease of its installation, relieved us of all our concerns.

The Vocal’Net telephony gateway’s 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.

Vocal’Net’s 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.

Vocal’Net is a standalone Internet telephony gateway server designed to integrate with telephone systems that support standard telecom interfaces. It has the following features:

  • 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 computer’s CPU.

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 Vocal’Net Database Program, which let us configure and manage the Vocal’Net telephony gateway.

Setting Up
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 Vocal’Net 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 gateway’s database. The Vocal’Net Database Program is a client/server-compatible application which allows the administrator to connect to any Vocal’Net telephony gateway on the network including the local gateway.

From the Connect-to-Server screen, we entered the New York server’s IP address in the Address field and clicked on Connect. We were connected to the New York server’s database and could now configure this gateway. Each gateway’s 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, Vocal’Net 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 Vocal’Net 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 Vocal’Net 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-Tel’s technical support department, which helped us identify the problem.

The problem was that Vocal’Net 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 Telephone Number).

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 Vocal’Net’s proficiency in reliably and efficiently transmitting voice over IP.

Invoking the Monitor program from Vocal’Net’s application folder launched the Monitor’s main window. This window is divided into two sections. The top section displays the messages received from the connected Vocal’Net 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 server’s address. After we entered the New York gateway’s 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 Monitor.

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 Vocal’Net 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 Vocal’Net 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. Vocal’Net, which is unaffected by the codec algorithms (it employs Microsoft’s GSM codec for voice transmission), performs this task well. For example, Vocal’Net allows the caller to dial extension numbers when the caller reaches a PBX.

Another Vocal’Net feature we liked was that it saved us the hassle of working with AG configuration or other hardware initialization files. Vocal’Net’s database program (the main administration application) was the only application necessary to set up and configure the system.

We found Vocal’Net’s 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 Vocal’Net, 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 Vocal’Net server. Vocal’Net 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 Vocal’Net Internet telephony gateways connected over a dedicated bandwidth from large backbone providers.

Vocal’Net demonstrates that telephony gateways will become a significant force in the telecommunications industry. Among the items we liked about Vocal’Net were ease of setup, excellent software, great voice quality, and ease of use. We were also very impressed by Inter-Tel’s knowledgeable technical support staff. These technicians successfully guided us through several problems.

Some areas of improvement for Vocal’Net 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 Vocal’Net. 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 Vocal’Net gateway, but also for its contributions to the advancement of telephony over the Internet/Intranet.

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].


© 2023 Technology Marketing Corporation. All rights reserved | Privacy Policy