Architectural Overview:
The IP 200 (which CommWeb tested -- the other model in ESI's IP Series is the smaller IP 40) is simple enough to look at -- a 19" rack-mountable black box with 10 card slots for various T-1/PRI (supports dual T-1 spans) and analog trunk interfaces, and analog phone equipment (the analog extension ports can be configured as standard 2500-type phones, night bell, fax, modem or door phone).
It also comes with 198 internal call-processing ports, 16 of which are for voicemail (internal memory module provides 140 hours of message storage) and auto attendant (the IP 40 contains 70 call-processing ports and two card slots and 16 VM ports).
Overall, a loaded IP 200 system (pictured with phones) can handle up to 66 CO lines and 30 analog station ports.
Being an IP-based PBX (actually, as already mentioned, more of a "hybrid" between traditional switch and next-gen IP-based machine), it also has an auto-detecting 10/100 Base-T Ethernet port and can support up to 96 IP feature phones. There are also connections for power, optional music/message onhold source, overhead paging system and a maintenance serial port (you can program the switch from a local or remote PC).
ESI also has a single port Remote Phone for its IP series (which CommWeb tested from its San Francisco homebase back to a switch in ESI's Plano, TX, office). This phone provides a fully functional off-site extension of an ESI IP-enabled phone system -- i.e. the same business phone features and functions of the in-office ESI Feature Phone.
It's identical in appearance to ESI's Feature Phone sets, but it does contain voice-compression circuitry that reduces its bandwidth requirements by approximately 80%, which is needed for obvious reasons in its application.
The main office and the remote site require a high-speed broadband connection. We ran it remotely on a DSL line in San Francisco back to a KSU in ESI's Plano headquarters; it worked fine. Again, all the same business-class phone features (of which there are a lot) and more than satisfactory sound quality.
A Remote Network Card (RNC) is required for offsite IP Telephony. It's an add-on daughter card that plugs directly onto the internal LAN Network Card (LNC) and adds the software and voice compression necessary to support the Remote Phones. According to ESI, two versions of the Remote Network Card are available: the RNC3 -- which provides three remote network channels; and the RNC12 -- which supports 12 remote network channels.
Each RNC remote network channel handles one active bi-directional conversation, compressing voice data from 64 kilobits per second (Kbps) to 8 Kbps in each direction using G.729a compression algorithms. Separate, dedicated data channels carry station data between the host system and Remote Phones providing display updates and lamp appearances.
A system with 12 compression channels can support 12 simultaneous Remote Phone conversations, consuming less than 550 Kbps of total bandwidth. It should also be stressed that the RNC's compressed channels are "pooled" and shared on a first-come-first-served basis. Therefore, more Remote Phones can be deployed than there are channels.
Although we did not test it, ESI also has something they call Esi-Link; it's for multi-site interconnectivity, i.e. tying together multiple offices, each with its own IP Series system.
One interesting and potentially critical note in Remote Phone use: since the Remote Phone functions as an extension of the IP phone system, "local" dial tone and 911 emergency access for the Remote Phone is made from the location of the IP phone system, not the location of the Remote Phone.
The ESI system also includes 24 conference bridges; a conference may contain up to four parties, so the IP Series can support six conferences of four parties each or eight conferences of three parties each.
ESI also reports a Windows based softphone for the system in their manual, but this product has not yet been released. They do ship a 64-key expansion console for the system.
Back To The Top Of The Review
Ease of Installation:
Although ESI has built this system to be right up a traditional interconnect dealer's alley, once you dive beneath the telephony-jargon surface it's really rather easy for even a layperson to sort out the system's architecture and program the machine correctly.
They have a Windows 95/98 program called Esi-Access -- which ESI is strict about calling a "dealer-only" application -- that makes all system programming very straight forward. It does include more telephony terminology than most pure PC-based and/or LAN-based phone systems, but, as a dealer-only system, that's not at all a problem. We were able to figure it all out -- including how to program trunk line access, voicemail and auto attendant -- without even consulting the 7-page Quick-Start Guide that came with the Esi-Access software.
It should also be noted that ESI told us that most of their certified dealer-installers typically program the system using the traditional method of touchtone access from a station set. So there.
During our testdrive of this system, ESI also sent us the latest version of their Remote IP Feature Phone software, which makes programming of the Remote Phones much easier. Chores in this area include programing Remote Phone IP addresses into the host system and vice versa. In system programming, the installer designates individual extensions as either "local" or "remote."
Once the programming is complete, the installer attaches each Remote Phone to the cabinet's Ethernet LAN or to the PC-based Esi-Address and assigns its extension number. The system automatically downloads into the phone's non-volatile memory its required addressing information.
One does need some sort of proxy router at the remote location. This because the phone and local PCs must have their own IP addresses (unlike on the LAN, where PCs are simply bridged through the phones). And the remote site's gateway device must be programmed to open the UDP port to the phone and forward it to the phone's IP address. When first connected to the remote site's LAN, the phone will automatically contact the main office system, log itself in, and -- if all goes well -- be available for use.
Most networks contain security provisions. In order for the Remote Phone to communicate with the host system, the network administrator must create voice communication "tunnels" through that security. This can be done by designating a UDP port through which all inbound traffic must flow, and then assigning or forwarding that port to a specific device or IP address.
