...
4.7 introduces support for Polycom 34.3 and above 0 firmware. It also removes discontinues support for firmwares below 3.1, as well as for phones SPIP 300 and 500. Instead it introduces support for VVX 500 model.
| Note | ||
|---|---|---|
| ||
4.7 removesdiscontinues support for firmware older than 3.1. That means thatHowever models SPIP 300 and SPIP 500 are no longer supported by sipXecs. Howeverwill continue to work with sipXecs. Most probably in a future release, support for those phones will be removed. Models SPIP 301 and 501 are able to work with firmware up to 3.1.8, thus they are still supported . However, 301 and 501 models are configured in 4.4 and 4.6 as Polycom SPIP 300/301 (500/501 respectively) which makes sipXecs unable to distinguish among a SPIP 300 and 301. In 4.7 you might have a situation where you have a SPIP300 phone working in 4.6 but after upgrade to 4.7 it will be displayed as a SPIP 301 with 3.1.X firmware. In this situation you are advised to manually delete the said phone. |
Admins will have to specify the phone version when adding/configuring a new or existing Polycom model. Firmwares currently defined are 3.1.X , 3.2.X and 4.0.X. In the future maybe finer grained versioning will be defined if necessary. Since in earlier sipXecs versions all Polycom phones are defined as having 2.0 version, there is both an automatic and a manual procedures to migrate the phones to the new system and to the correct firmware version. Both are described below.
Another major difference is that multiple firmware versions can be activated simultaneously. This way, an admin can define multiple phones or groups of phones with different versions. Firmware applications together with whatever files packed in the zip archive downloaded from Polycom site will be unpacked in specific folders in tftproot.
| Note |
|---|
Note that by multiple versions we understand at most one firmware per major version defined. For instance we will not be able to have 3.2.6 and 3.2.7 versions deployed at the same time, since they would both go to tftproot/polycom/3.2.X folder. |
| Note | ||
|---|---|---|
| ||
In 4.6.0 some phones were defined as paired models, since they had the same configuration. In 4.6.1 the models have been split. On migration, phones will be able to automatically pick up the correct model. Also a combo box was added in the phone's page for the specific models, in order for an admin to be able to manually choose the correct phone model. The models are (all phones are SPIP):
|
Installing firmwares
The Device files interface for Polycom firmwares has not changed visually, except for adding a new Version field - a combo with "3.1.X", "3.2.X" and "4.0.X" values. An admin should choose the correct version of the firmware installed. By doing that the admin will ensure the firmware will be unpacked in the correct folder.
...
Installing bootrom
| Note | ||
|---|---|---|
| ||
| While not disallowed by sipXecs, it is strongly discouraged to have multiple bootroms deployed. |
...
After updating to 4.7 phones will reboot twice. The first time the [MAC].cfg will be changed in order to instruct the phone to contact the provisioning servlet. The provisioning servlet will read the correct firmware installed on the phone (using the User Agent header of the phone's request) and then via a sipXconfig REST service will update the phone's firmware version in the database. On second reboot sipXconfig will generate the correct config files which phones will pick up. Both reboots are scheduled after 1 minute to give phones time to register.
| Note | ||
|---|---|---|
| ||
| Phone Auto-Provisioning role must be enabled in order for the automatic migration to take place. Also make sure that firewall rules do not prevent phones from contacting provisioning server which by default runs on port 8185. |
...
If somehow the automatic procedure fails for some of the phones (for some reason the phones could not have been rebooted, for example they were not registered at the time of the migration) admins may try to manually reboot the phones (listed in the failed jobs table). Phones should pick up the correct version and configs.
Note that even without migrating the phones, they should continue to function.
If, for instance some phones are behind a network and firewall rules prevent them to reach auto-provisioning servlet, or the auto-provisioning role is disabled, the phones might not function properly (they might keep rebooting), and admins will have to take some actions to bring the phones back up. The most important is to generate the correct profiles for the phones. In order to do so, admins will have to choose the correct firmware the phones have installed or upgrading to a greater version (check out below to see how to bulk upgrade a group of phones). For particular models admins must choose correct model first, in order for the list of the supported firmwares.
Bulk updgrading Polycom firmware on phones
...
If you have a phone compatible with 4.0 but you DO NOT WANT TO UPGRADE it to 40 4.0 and keep it to 3.2 version, you must make sure you do not keep the Upgrader deployed. If you do so, on reboot the phone will pickup the new bootrom and try to find a compatible image in the 3.2.X or 3.1.X folder. Those images are not compatible with the upgrader, and you will get a "Image is incompatible with the phone" error.
...