I am afraid I cannot, in good conscience, recommend anyone purchase this or any other Polycom product. There are several bugs with these phones that I can reproduce (see below). It is not realistic to expect every problem to manifest itself in every situation. Some poeple may never see the problems documented below.

A lot of products have bugs, and in most cases the manufacturer takes an interest in bug reports and fixes the problems. I have spoken with several people at Polycom (Mike Ellis, Charles Lee, etc.) and told them about problems I have documented, but they have made it clear that they no intention on following up on my reports.

If you do not purchase their products from an authorized reseller, forget about any type of support aside from blatantly obvious hardware problems. I was unable to find a list of authorized resellers anywhere on the polycom website. I was also unable to find anything stating there would be no support if I didn't purchase from a company on this list.

Product information: http://polycom.com/products_services/0,1443,pw-34-182-3025,00.html

Polycom does not provide operational support to End Users.

Polycom support thier phone for use by specific authorized systems. As such, they provide support directly to the developers of the authorized systems. When you buy a VoIP system from a Polycom Technology partner, the vendor of that system is your point of contact for operational support of that system. When you buy a polycom phone for your Asterisk system from an authorized Polycom dealer, that dealer is your point of contact for operational support issues. Most, if not all, authorized Polycom dealers will pass along legitimate bug reports to polycom. To purchase phones directly from Polycom, you must the an authorized reseller. To become an authorized reseller, you must certify with Polycom on one of their supported platforms. Polycom will accept bug report from their technology partners and their authorized resellers.

This is analogous to your regular telephone service. You order phone service from ABC telephone company, and you buy a telephone made by XYZ company. You have a problem with the phone... ie: you do not get the message waiting stutter dialtone when you have a message waiting. Do you call XYZ company? No, you call the ABC telephone company to make sure that they actually have your voicemail configured correctly. If the problem is that the phone does not provide any dialtone (ie: the handset speaker is broken), then you call the manufacturer of the phone (or your vendor) to get the phone replaced.

This paradigm is used throughout the consumer products industry. Your Phone manufacturer will not support issues that should be dealt with by your phone company, your TV manufacturer will not support issues that should be dealt with by your cable or satellite company, your computer manufacturer will not support issues that should be dealt with by your internet service provider. The list of examples goes on and on.

If you are using Asterisk as your VoIP system, then you are the VoIP service provider. If you find a genuine bug in the Asterisk software (and not just a configuration problem), report it to the bugtracker (providing the prerequisite debug logs) and the issue will be looked at by a very dedicated and talented group of people that are very willing to look at the issue. If you find a bug in the way the Polycom phone is working, report it to your phone vendor.

Polycom DOES provide hardware support and replacement for defective phones to End Users.

Polycom phones work resiably and without isuue on a correctly configured Asterisk system.

Dbruce

Problem

After an upgrade to SIP 1.4.1, the phone will freeze on the "Welcome / Processing configuration..." screen, if the following conditions are met:

Phone initially has SIP version 1.3.0, 1.3.1, or 1.3.4 on it. (Possibly any prior version)
Settings > Network Configuration has the following settings (As an example):

 DHCP Client: Disabled
 Phone IP Addr: 192.168.002.023

 Subnet Mask: 255.255.255.000

Workaround

Before upgrading, change Settings > Network Configuration to the default settings of:

 DHCP Client: Enabled
 Phone IP Addr: 000.000.000.000
 Subnet Mask: 000.000.000.0

If you have already upgraded to SIP 1.4.1, downgrade to a prior version to make the configuration changes, then upgrade back to SIP 1.4.1.

Problem

With BootROM 2.6.1 and from (at least) SIP version 1.3.1 to 1.4.1, the phone will freeze up after being on for several days. There is no discernable pattern as to when it happens, and no way to predict it. Holding the reboot keys (Volume-, Volume+, Hold, and Messages) on the keypad does nothing.

Workaround

1. Remove power from the phone for a moment. After power is restored, the phone will boot up normally.
2. Reboot the phones manually every 2-3 days to prevent the freeze up. (See Polycom reboot hardphone script for one method of automating this.)

Additional Information

This problem has not been fixed as of SIP 1.4.1.

(dbruce) This problem does not occur with SIP v1.5.2. I have units that have 60+ days of uptime without any issues.

Problem

Even with the latest BootROM (2.6.1) and SIP software (1.4.1), stray pixels appear on the screen. They are usually, but not always, in the area just above where it would say "XX new missed calls."

Workaround

These are nothing more than an annoyance and usually go away on their own. If it really bothers you, you can reboot the phone.

Caveat

Between sip v1.3.1 and v1.4.x, Polycom changed the positioning of screen elements to resolve some problems with stray pixels. If you did not update your ipmid.cfg when updating to v1.4.x, you will not benifit from these corrections. Further changes were made to screen element positioning were made with the release of v1.5.x.

If you use an idle image, stray pixels in the lower portion of the screen can also be an indication that your image is too large. The maximum size of an idle image for the IP500 is 112 pixels wide by 52 pixels high. (See Polycom Idle Images )

Problem

Confirmed with BootROM 2.6.1 and SIP version 1.4.1, the phone will, at first, become sluggish or even stop responding altogether, and then reboot itself when there is heavy traffic on the network. I have seen the phone stop responding in as little as 1 second and reboot in under 3.5 minutes.

Workaround

Place phones and PBX on separate subnet and/or VLAN from computer traffic. Even then, with enough VoIP traffic you may still see problems.

(dbruce) This issue does not occur with v1.5.2 under simulated load conditions. (tested in a lab environment using 10 phones on a 10MB lan using 60 second registration, multiple presence subscriptions, multiple simulaneous active calls and simulated network load)