December 1998

TMC Labs' Gateway Shootout (Part I)

As Internet telephony gateways evolve from a fringe technology to a mainstream tool, their developers face the challenges of integration, reliability, audio quality, and gatekeeper functions. Covering the trend, TMC Labs is shifting its gateway testing methods from qualitative and stand-alone testing to quantitative and comparison testing. We will test T1 and fax options of gateways in the future, but Part I of our shootout is dedicated to the analog voice functionality of gateways from Inter-Tel, Linkon, and Nuera, based on a PC, a Sun platform, and a black box, respectively. We also chose these gateways based on their installation process, documentation, support, competitive pricing, and mainstream availability. Equipment we used included the Hammer IT 2.1.3 software and the Hammer VoIP 2.0.2 test suite, plus a TLS-4 analog line simulator from the Teltone Corporation. You can visit the Web sites of these companies at www.hammer.com and www.teltone.com, respectively.

TOOLS & METHODOLOGY
The most important aspect of this equipment was Hammer's VoIP suite. Earlier versions of the Hammer IT VoIP suite included Perceptual Speech Quality Measurements, but version 2.0x is the first version to include testing for speech latency. Midway through our tests, Hammer provided us with an even newer revision because Hammer's disconnect tone conflicted with Linkon's handshake tone. This conflict is explained below in the Operational Testing section.

An important part of the prompt test is measuring latency. This works by listening for DTMF tones that have been played and time-stamped at the originating Hammer channel. These tones travel to the local gateway, where they are compressed, packetized, and sent across the network. At the remote gateway, the packets are reassembled, decompressed, and sent to the terminating Hammer channel, where they are time-stamped again. The difference between time stamps equals the latency. This path consists of an analog line connection stemming from one channel on the Hammer to the first gateway, a compression phase (2) at the gateway, a network connection (3) to another gateway where the speech undergoes a decompression phase (4), and finally, another analog connection (5) from the second gateway to a terminating channel (final destination phone number) on the Hammer unit. This provided us with five distinct phases that all speech would travel across: Two analog line connections, a compression and decompression phase, and a network path connecting the two gateways.

Our goal was to examine only the latency introduced by the gateways because of compression and decompression algorithms, so we had to minimize the latency effect of the analog and network connections (phases 1, 3, and 5). Better gateways don't just compress and decompress the voice, they do it as quickly as possible to minimize any latency introduced.

The IP network between the two gateways was easy to manage because we used a "clean" network with a 10-BaseT hub connected only to a PC running Gatekeeper and network management software. Meanwhile, the analog circuit between each gateway and the Hammer channels depended on whether the gateway being tested used FXS ports, which provide their own dial tone, or FXO ports, which need dial tone provided to them. Only the Nuera gateway used FXS ports, so we connected it directly to the Hammer system. The Inter-Tel and Linkon gateways used FXO ports, so we used the Teltone simulator between the Hammer and the gateways to generate dial tone. For these two gateways, we also subtracted the Teltone-induced latency (12 milliseconds for each half of the Hammer-to-gateway circuit) from the final figures.

Another important component of the prompt test are the PSQM scores, which determine the quality of speech according to the benchmark assessment of a group of human judges endorsed by the International Telecommunications Union (the ITU-T P.800 and P.861 standards). Visit the ITU's Web site atwww.itu.org. The algorithm plays sound clips chosen for the range of sounds that they produce, not for the clips' actual meaning, which tend to have an eerie and nonsensical nature. (Examples include "I worship wooden idols … I want a minute with the inspector;" "You will have to be very quiet … There is nothing more to be seen;" and a nasal man's voice drawling over the word "hello.") Each of the sentences is read in a male, female, and child's voice, encompassing a range of tones. Like the DTMF tones in the latency test, the sound clips are compressed, packetized, sent across the network, and decompressed by the remote gateway, which plays the clip back to the Hammer. The Hammer then takes this signal and passes it to the PSQM algorithm along with the original prompt from the voice library. The PSQM algorithm compares the received prompt to the original one and reports a PSQM score.

To complete our testing procedure, we configured the prompt test to produce 100 test calls with sufficient time between calls for each gateway to disconnect and reset itself for the next call. We found that 50 calls per hour provided an adequate time-out between calls. We performed the prompt test four times on each set of gateways: once for latency testing and once for PSQM scores, using two compression schemes. Finally, we also ran the PSQM test on the Teltone unit, but the results of this test are for comparison purpose only. As Hammer engineers explained to us, the PSQM scores are non-linear and are attained using complex algorithms. Trying to "subtract" the Teltone's PSQM scores from a gateway's actual scores would not give an accurate figure.

THE PARTICIPANTS

Inter-Tel, Inc.
7300 West Boston St.
Chandler, AZ 85226-3224
Ph.: 800-669-5858
www.inter-tel.com
[email protected]

Price (approximate): 8-port, $4,500/port; 24-port, $1,000/port; call for more details.

Inter-Tel's Vocal'Net 1.2 is a PC-based Internet telephony gateway that supports both voice and fax over digital T1 and E1 and analog WTI-8 and AG-8 interfaces. The gateway offers four compression modes - GSM120, GSM40, G.723.1, and G.711 - and is compatible with a large variety of PBXs and CO stations. Unit programming and maintenance is accomplished through a well-designed Windows GUI, as well as several DOS-based monitoring functions.

INSTALLATION
We tested an eight-port analog AG-8 gateway, which has minimum system requirements of a Pentium 133 or greater running Windows NT Workstation 4.0 with Service Pack 3, 24 MB of RAM, a one gigabyte hard disk and capacity for three full-size 16-bit PCI cards. Starting with a "clean" PC running Windows NT (but not the service pack - that comes last), users install the AG-8 card, the AG-DSP/RT card and the TX-2000 LAN card. The three cards are linked using a 40-pin MVIP ribbon cable. Next, users install an optional fax card, then the Vocal'Net software, followed by the NT Service Pack.

Perhaps it was just because our test PCs were brand new, but we found the cards difficult to install. Setting them into the appropriate slots took an unusually large amount of physical effort. This concerned us, because we were afraid that too much pressing on the cards could damage them. To protect against this, we took extreme caution when pushing the cards into the slots. The AG-DSP/RT card did suffer a bit - it had a daughter card attached, which tended to separate from the main card. We removed this card and determined that the damage was purely cosmetic, then re-set it. It worked fine. Finally, we connected each machine to a hub.

Configuring the Vocal'Net software was more tedious than installing the hardware. After running the setup wizard and rebooting each machine, we connected to the server using the default values for the IP address and password. We chose the menu option "network-table-load" and then opened the PSTN-to-IP routing table. Algebraic-style dial patterns and dial rules are used to determine who can call whom. Here, users also determine the call-billing rate if one is desired, plus gateway name descriptions, fax options, and SPID (Service Provider ID) options.

Once these options are saved on each unit, the next step is configuring options under the Miscellaneous Options Table. As its name suggests, this menu has a variety of features, including server password, prompt language, maximum number of simultaneous calls and vocoder type. In particular, we needed to change the Inter-Digit Timer in order for the Hammer unit to send the DTMF digits without a time-out message. The Inter-Tel came to us with a factory preset of 5,000 ms. We changed this to the minimum allowable interval of 1,000 ms so we could complete our testing.

DOCUMENTATION
Our user's manual was still a preliminary version, but we're very impressed so far. The manual's 11 chapters cover installing digital and analog gateways, programming, PBX setup, monitoring software, network management, and troubleshooting. There are diagrams, charts, and illustrations throughout. We especially like that the document is written in language simple enough for a typical MIS manager to understand: Users do not need advanced telecommunications degrees to configure an Inter-Tel Vocal'Net gateway. We also like that there is significant discussion of compression schemes and the Internet telephony concept. The troubleshooting section is equally detailed. We like this manual for its attention to detail, and we strongly suggest reading the appropriate chapters before attempting any installation. It can be overwhelming for a first-timer. Overall, we feel that this manual is very good, and the complexity of the product makes the simplicity of the manual that much more impressive.

FEATURES
Certain Vocal'Net features stand out, although we didn't utilize all of them. The entire unit is programmable through text files, and every prompt is a documented .WAV file that can easily be changed. We also can't overlook the numerous call accounting features and fax options, many of which make Inter-Tel's gateway different from the competitors. Our favorite feature is the monitor program. Monitor has the same no-frills environment as the Vocal'Net programming database, and offers event logging, password protection, configuration of network options, helper application selections, and system information. Other features include:

• Supports caller ID and ANI data.
• Jitter-Buffer.
• Automatic database upgrade.
• Customizable IVR.
• Natural MicroSystems Fusion II support.
• ODBC-compliant SQL database.
• Oracle 7 support.
• Year 2000 compliance.

The four compression schemes that the gateway offers are the standard supplied by the Natural MicroSystems Fusion-based line of products. These are:

• GSM120 and GSM 40, compressing speech at 13.3 Kbps.
• G.723.1 with silence suppression at 6.4 Kbps.
• Both a-law and mu-law G.711 at 64 Kbps.

Linkon Corporation
140 Sherman St.
Fairfield, CT 06430
Ph: 203-319-3128
Fx: 203-319-3150
www.linkon.com

Price: 4 channels - $18,189; 8 channels - $23,238.

The LinkNet is a Sun Microsystems based Internet gateway that runs under the Solaris operating system. The gateway is designed to function both as an IP switch and as an enhanced services platform capable of handling fax, interactive voice response, and speech recognition. Currently, the LinkNet has been deployed with a variety of applications including phone-to-phone communications over satellite networks, prepaid calling card services, Java Phone call center applications, and in Internet and Intranet configurations - both domestically and internationally.

INSTALLATION
We received two LinkNet Gateways as fully turnkey systems, entailing two gateways and two Sun Sparc stations for controlling the gateways. Supposedly, all we had to do to make the gateways work was follow a few simple directions - connect all the wires for the gateways and the Sun computers, connect them on a LAN and run a sample application. After we completed this setup, with the use of the Teltone Simulator and two analog telephones, we were able to make calls from a port on one gateway to another port on the other gateway. When we put the Hammer system into the circuit, however, we encountered one of the more interesting troubleshooting sessions in some time.

At first, it seemed as if the Hammer was unable to connect phone calls though the gateway system. The Hammer would place calls through the Teltone unit to the first gateway. This required multistage dialing in order to get through the LinkNet's greeting menu, but immediately after navigating this menu, it seemed that the Hammer was unable to make a connection.

We called both manufacturers (Linkon and Hammer) and explained our situation, and we went through an assortment of specifications about the boards that were used in both products. What we found was that the two devices should be working together properly, or at least, there was no physical reason that they should not.

This prompted us to delve further and examine the log files on the Hammer PC. What we found was the calls were being connected, but that the connections were being terminated before the Hammer could run its first leg of the test. With this knowledge in hand, we tried to find the command in the Prompt Test script that was causing the LinkNet to disconnect, but we were unable to determine the cause.

Rather than waste too much time searching for the proverbial needle in a haystack, we called some of our contacts at Hammer and began to retrace the Hammer's commands. All seemed remarkably commonplace until our contact mentioned that the Hammer system sends an asterisk DTMF tone to handshake. Our contact did not need to say anything more, as we had found the answer to our dilemma: The asterisk. As it turns out, this tone had a special function for both devices. For the Hammer, it was used to handshake and establish connectivity. Ironically, Linkon uses the same tone for disconnecting a call. The attempt of the Hammer to handshake was actually disconnecting the calls.

To take care of this situation, Hammer arranged to write a new beta for the VoIP suite that did not use an asterisk anywhere during the operational testing so that it would comply with the LinkNet gateway (and by extension, any gateway that uses an asterisk to disconnect). A few days later, we upgraded from the VoIP suite 2.0.13 to the brand-new 2.0.20. We set the test configuration and were relieved when the Hammer was able to run through the Prompt Test without inadvertently disconnecting the call. It is important to note that despite our troubles in getting this test to work, we hold no one to blame as both the Hammer and the Linkon devices were performing according to their specifications. The outcome is that the Hammer suite has now been successfully tested with yet another gateway manufacturer and for that, we are pleased to have played our part in getting the Hammer to "get along" with the Linkon gateway.

DOCUMENTATION
Documentation for the LinkNet came in three separate compositions. Two of these are fairly lengthy guides that seem to be exhaustive in their detail. One of these manuals covered the installation of the LinkNet gateways and a configuration guide to help the user with sample applications. The remainder of this manual, and the entirety of the other, deal with programming in the TeraVox/LinkNet space and technical specifications that only a board developer could love.

The other form of documentation came to us in an uncomplicated two-page quick-start guide that actually provided most of everything that we testers needed to know. Following the commands on these sheets in a top-down manner successfully set up the sample application, even though it took us a long time looking through the larger manuals and on the phone with the manufacturers to realize that this was the case. Since the delay was caused by a temporary incompatibility between the Hammer VoIP suite and the LinkNet, it turned out the documentation for the LinkNet was accurate and should be rewarded for its completeness.

FEATURES
The LinkNet functions as both an IP switch and an enhanced services platform, and is capable of supporting fax, interactive voice response, and speech recognition. LinkNet can provide both voice and fax over IP, with an IVR front-end, and a wide variety of signaling and call control functions.

The LinkNet offers open software architecture with SS7 integration and hardware-based echo cancellation with Lucent's TECO chip. It supports from four analog ports to a full digital T1. It also can achieve capacities of up to 96 ports in a single-node server configuration.

Linkon achieves up to two channels worth of full-duplex transmission at the DSP level eliminating the need to physically bridge the two channels together. So, a four-port, four-DSP analog board can provide four full-duplex Internet phone conversations. The LinkNet also employs multiple compression algorithms on the DSP, and comes with compression algorithms for mu-law G.711 at 64 Kbps, GSM 601 at 13 Kbps and a sub-band coder at 24 Kbps. The LinkNet gateway also provides echo cancellation as a standard feature.

The Linkon gateways also support integrated enhanced services such as IVR, speech recognition, and speaker verification. In addition, the LinkNet has the ability to dynamically switch among available call routes (Internet, intranet, or PSTN) and switch among the different voice compressions for selectable voice quality.

Nuera Communications, Inc.
10445 Pacific Center Ct.
San Diego, CA 92121-1761
Ph.: 619-625-2400
Fx.: 619-625-2422
www.nuera.com

Price: $1,000/port.

Nuera Communications produces the Access Plus series, a gateway that offers voice and data integration over IP, frame relay, and TDM links. We tested the AccessPlus F200IP model. The AccessPlus F200IP's voice ports support a variety of analog and digital interfaces and are compliant with most voice signaling protocols. This model runs voice over IP and voice over frame relay concurrently and can switch voice calls between any connected ports over any supported protocol. These protocols utilize dynamic bandwidth allocation with a range of compression rates from 4.8 to 32 Kbps. In addition, the model supports other data equipment, such as IP routers, FRAD devices, and asynchronous transport protocols.

INSTALLATION
We received two AccessPlus F200IP units that came to us as turnkey systems. These two units were black boxes and are configurable through any terminal emulation software or through HP OpenView. Because our systems were small in scale, we used Windows' built-in HyperTerminal program by connecting a DB15 cable from each gateway to a PC. We powered on each unit, waiting for the finish of the five-minute LED test sequence before the units transmitted information to the HyperTerminal program. We supplied a password and IP address for each unit, and we set the date and the time for the system clocks.

The next step we took was to install the NueraView network management program on a PC running Windows NT. This installation went without a hitch, though NueraView seemed to install a countless number of small sub-programs, causing the installation to be a time-intensive process. When we had the programs running, we set up a call routing table configured for the two gateways.

With both units configured with IP addresses, we connected the two units across a simple LAN. We connected each unit to a network hub that we kept separate from our corporate LAN to eliminate "bursty" network traffic from affecting the results on this LAN. To test our setup, we connected a computer to the network hub and opened a DOS window to see if we could ping the units via their IP addresses. What we found was rather interesting. We were able to ping the first unit; the second unit would receive ping replies, but many of them would give time-out messages. We found this highly unusual, so we called our contact at Nuera and explained the situation. He explained that there was a high demand for people to test Internet gateways, and as a result, millions of dollars worth of equipment was making the rounds across the world. This pertained to us especially since it seemed that the gateway's network card had been damaged during shipment. We received the replacement network card the next day and installed it. After we switched the two cards, we proceeded with our tests. Thankfully, we were able to ping the unit after replacing the damaged network card.

We were pleased that the change of network cards had solved our problem, so we decided to call our contact and mention that all was well. While we were on the phone, we described our operational testing procedure so that he could formulate the commands that would set up our call flow. We explained that we wanted to automate the call flow from one port on a Nuera unit to another port on the other unit by using the Hammer unit, and as a result, he faxed us a list of instructions to be keyed in through the HyperTerminal program. We typed the commands for both units and tested the current setup by connecting two analog phones to the gateways and making a call. Strangely enough, the moment we picked up one phone, the other phone rang immediately without waiting for us to type a phone number. Knowing that there was no way for the Hammer to work with this configuration, we called our contact back and explained that the Hammer required a phone number to run through the script. With this new information in hand, our contact drew up another set of commands for us. Once again, we used the HyperTerminal program to enter these commands for each unit. With these changes in place, the systems were set up so that the gateways could take calls from an analog phone and transmit them over the LAN segment to the other gateway.

DOCUMENTATION
The documentation for the Nuera gateway was supplied to us in Adobe Acrobat format on a CD-ROM that came with the units. The total documentation was comprised of five such files. We found three of these particularly useful. These were the manuals titled Getting Started, Installation and Maintenance, and the User's Guide. Each of these dealt with a particular area that directly impacted our setup. The remaining two files were the General Information Manual and the Programmer's Reference.

It should be noted that each of these Acrobat files was meticulous. Basically, if we wanted to know something about the gateways, we knew it could be found within the manual. Finding the information was another issue altogether. Even though the files were amply indexed, the size of the files made it difficult to find very specific information. However, we did find specific areas where the files were invaluable, such as command summaries so that we could configure the systems or change the compression algorithms.

FEATURES
The Nuera Access Plus F200IP provides flexible voice interfaces. It can be configured with a T1 interface for 24 channels or an E1 interface for up to 30 channels. The T1/E1s eliminate subsequent distortion due to digital-to-analog conversions. In addition, analog interfaces are programmable with as FXO, FXS, and E&M channels. The AccessPlus F200IP provides a wide range of voice compression technology. These include:

• Proprietary E-CELP algorithms operating at 4.8, 7.47, and 9.6 Kbps.
• Standard algorithms G.728 LD-CELP at 16 Kbps, G.726 ADPCM at 32 Kbps, and an optional G.729 CS-ACELP at 8 Kbps.
• Group III fax support at 2.4, 4.8, 7.2, and 9.6 Kbps.

In addition to these voice compression algorithms, Nuera utilizes a number of other technologies to minimize network bandwidth. Silence suppression minimizes the bandwidth usage during speech breaks while maintaining a level of ambient background noise for a natural sounding conversation. Through the use of programmable voice packetizing, bandwidth efficiency can be improved, while data fragmentation is configurable on a DLCI basis to minimize delay of voice traffic over low-speed interfaces. In addition, the Nuera contains asymmetric fax channels that minimize the bandwidth usage on the return path. The Nuera AccessPlus 200IP model can also employ one or two FRAD data interfaces in addition to digital and analog ports. These FRAD ports can be utilized in an asynchronous method ranging from 75 bps to 115.2 bps and as synchronous FRAD devices from 1,200 bps to 2.0 Mbps. Other features of the Nuera Access Plus F200IP include:

• A jitter buffer to minimize end-to-end speech delay.
• An Integral echo canceller that adapts from 0-49 ms to guarantee consistent voice quality over long tail circuits.
• Voice compression rates are negotiated to provide configuration flexibility.
• Modem transparency over voice channels.

The AccessPlus F200IP provides complete call processing by switching each call independently with full digit and interface translation. This minimizes the number of ports needed and also minimizes the cost of using the voice network. Digit translation provides a unified dialing scheme capable of 20-digit translation and 40-digit outpulsing. Furthermore, the ports on the Nuera are completely interoperable with each other, and calls can be made between any types of ports (i.e., analog, digital or FRAD).

NueraView (for HP OpenView) provides configuration, statistics, diagnostics, and alarm management for the network of gateways. The database in NueraView assures that the important configuration information is safely backed up while multiple network managers can access the network and view the information held within the database.

OPERATIONAL TESTING

• Inter-Tel G.723.1
  The Inter-Tel gateway we tested came with a number of different compression algorithms. These included GSM40, GSM120, G.723.1, and G.711 (both a-law and mu-law). The first compression that we tested was the G.723.1 codec, which compresses voice at about 6.4 Kbps with the use of built-in silence suppression. We ran the prompt test on the Inter-Tel in an FXO port configuration, meaning that the test needed the use of the Teltone Simulator. The numbers we received showed that over the full path, the latency of a packet was about 177.5 ms. Subtracting the 24.0 second latency inflicted by the Teltone unit left us with 153.5 ms of latency caused by the compression and decompressions schemes. This amount of latency places the Inter-Tel G.723.1 within the lower third, behind all but the Inter-Tel GSM40 algorithm. Even though the G.723.1 codec had a high latency, the PSQM scores show that the sound quality of this codec is among the best we tested. In this regard, only the Nuera G.729 compression scored better, but it should be noted that the Nuera did not employ the use of the Teltone simulator. Without a definitive method of determining the exact effect of the Teltone on PSQM scores, comparisons between the two test setups based on the PSQM criteria cannot be made conclusively.
  
  
• Inter-Tel GSM40
  When we chose to test another compression for the Inter-Tel gateway, we were left with a decision between the GSM40 and GSM120 algorithms. Researching the specifications on each showed that the two algorithms compressed voice equally (13.3 Kbps), the only difference being the packet size. Since the GSM40 algorithm creates smaller packets, we felt that this algorithm would stand a better chance in the real world, so we decided upon that algorithm. What we found was that this compression suffered the worst latency of the various compressions we tested, but furthermore, the speech quality scores also suffered.
  
  
• Linkon GSM601
  After we got the LinkNet Gateway functioning with the Hammer unit, we ran through both the latency test and the PSQM test and tabulated the data. We received data that placed the LinkNet squarely between the Nuera and the Inter-Tel in terms of latency. We determined that it was running on the GSM601 compression algorithm by default. PSQM scores for the Linkon, however, were not as favorable, though we should note that to our ears, the speech was tolerable, hardly different than audio you'd hear on an analog cellular telephone. Unfortunately, the other compression algorithms that the LinkNet uses were not within the range that we were testing, so we only tested the GSM601 compression.
  
  
• Nuera E-CELP
  When we received the Nuera gateways, they were already set to handle the incoming voice with their proprietary E-CELP algorithm that compresses data to 9.6 Kbps. The Nuera was the only machine that used FXS ports, and the latency numbers we received for the ECELP compression were already lower than all the other Nuera compressions. However, this did not prepare us for how low the latency figure would actually be. Even after we subtracted the effect of the Teltone Simulator, the Nuera E-CELP still only had about half the latency of the other two gateways, making the Nuera AccessPlus our top performer in that category. The speech quality scores also ranked in a respectable range. Testing the system with analog phones to our ears only confirmed the tests Hammer's results produced, as the latency was almost indistinguishable, even when looking directly at the other speaker.
  
  
• Nuera G.729
  Nuera had the largest array of compressions of the gateways we tested, ranging from 4.8 Kbps all the way up to 32 Kbps. We chose the G.729 algorithm since it compressed voice to about 8.0 Kbps and is a fairly common compression. When we tested this compression, we found that the latency barely changed at all from the numbers for the E-CELP compression. Even better, the PSQM scores actually improved. Since we could directly compare the G.729 algorithm to Nuera's proprietary E-CELP, we could see that the G.729 definitely performed better. Since the PSQM scores for the Inter-Tel G.723.1/Teltone configuration were slightly worse than those for the Nuera, even removing the effect due to the simulator would only make them approximately equal in this regard. This left us comparing the latency scores of the two gateways, which made Nuera the clear leader.

CONCLUSION
And the winner is… Nuera's "black box" Access Plus F200IP, running the G.729 compression, followed by Inter-Tel's Vocal'Net 1.2 running the G.723.1 compression. The GSM compressions we used on the Inter-Tel and Linkon gateways did not fare as well, and although Nuera's ECELP compression kept the same low latency figure as the G.729, it significantly increased the PSQM scores.

We hope to see more competitors in the Internet telephony gateway field come through our laboratory in the near future. We'd also like to remind readers that we developed our testing methods with the goal of comparing the gateways to each other in a laboratory environment. There performance in our labs may not rate the same in a real-world utilization, where the scale would be much larger and where other software features may be implemented, and we also remind readers that our tests focused on testing the gateways, not the networks and environments they sat in. For example, we didn't consider factors like each gateway's jitter buffer, which are usually dynamic in their adjustments. Moreover, certain gateways might be better suited for certain applications - one may work best for straight IP voice, another may excel at IP faxing, still another could be considered the king of frame relay video conferencing.

Our tests should be only one part of your purchasing decision. We strongly recommend attending industry events, visiting corporate Web sites, and insisting on seeing (and hearing) demonstrations before making any buying decisions. Consider price, scalability, support, integration, interoperability, and ease of use as well. Regardless of which gateway you decide to purchase, we urge all organizations to keep in mind the cost savings, added efficiency, and enhanced services available by using the features of a packet-switched data network instead of a circuit-switched one.