SIP phones have a lot of functionality, all of which must be managed. For example, in a typical enterprise setting, every phone needs the name of a SIP proxy server set in its configuration. The proxy server is used to route calls. In theory, SIP lets you make calls in a peer-to-peer mode without the use of a proxy server, but this requires that the caller maintain the location of all the other phones. It works fine for calling a few friends on the Internet, but it doesn't scale.
Each phone also needs the address of a registration server, so that it can maintain its presence and status on the network, as well as such mundane items such as IP address and subnet mask, for example. Although it is possible to enter a lot of this information on the phone manually, we found it very labor-intensive and tedious. Because the phone interface is optimized for the end user (as it should be), administrative functions were usually buried under layers of submenus.
The most scalable solution is to download configurations remotely via TFTP (Trivial FTP). DHCP plays a role here. Along with the IP address, gateway address and DNS servers, we used DHCP to inform the devices of the TFTP server address. The phones could then use this address to download a configuration. TFTP could also be used to upgrade the software image. A common way to identify unique configurations for each phone is to tie it to the phone's Ethernet address. It's possible to have a file on the server with the Ethernet addresses as part of the name, which makes the association.
We found troubleshooting more difficult with VoIP phones than with legacy devices. First, messing with any one of the configuration options often caused the phone to malfunction. The phones can lock down these settings with a password. Also, the data network that the phones use for transport can cause problems. For example, if there is too much congestion, call quality will suffer.
All the phones except the Zultys provided access to major configuration parameters via a Web interface, which we used to quickly verify the configuration. Also, the Polycom phone provided a number of useful statistics available from the display. We checked on packet jitter, packet drops, network utilization and even the CPU utilization of the phone.
Still, we would have liked even more troubleshooting options for the phones in general. For example, it would have been useful to be able to access the statistics that the Polycom phone kept remotely.
We were also interested in the pricing for the phones, because standards encourage competition. Prices ranged from $250 to $440, but keep in mind that these are retail, and discounts are common. Also, these prices include all software licensing necessary to make the phones operate. If you look at our features chart online, you'll see there are no hidden costs for additional software. That's the way it should be.
After months of crystal-clear calls, with only a very rare pop, the range between first and last place was less than 0.5 percent, with three of the five tying for second. Still, only one can emerge victorious, and Polycom's SoundPoint IP 600 took our Editor's Choice award. We liked the SoundPoint's rich feature set, and we found it to be the easiest to use of all the phones tested.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
REPORTS
ANALYTICS
Follow 
