Changes in 4.7 Provisioning for Polycom

Overview

4.7 introduces support for Polycom 3.3 and above firmware. It also removes support for firmwares below 3.1, as well as for phones SPIP 300 and 500. Instead it introduces support for VVX 500 model.

SPIP 300/301, 500/501 models

4.7 removes support for firmware older than 3.1. That means that models SPIP 300 and SPIP 500 are no longer supported by sipXecs. However 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 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.

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.

Phones and versions are connected through the phone's Firmware version field. A phone that has "3.2.X" version will look for the SIP application in the tftproot/polycom/3.2.X folder - the [MAC].cfg file is configured to accommodate this. Configuration files are kept in the tftproot folder just like before 4.6.1.

Admins can deploy multiple (major) firmware versions. You can have a 3.1.X, a 3.2.X and a 4.0.X firmware deployed for the situation in which there are multiple phones with different firmware versions.

Older Polycom Device Files

Please note that Polycom device files installed in 4.6 (be it active or inactive) will be deleted on upgrade. Admins are advised to re-add the device files for the wanted firmware.

Installing bootrom

Note

While not disallowed by sipXecs, it is strongly discouraged to have multiple bootroms deployed.

To install a bootrom you need to upload and activate the bootrom in any of your Polycom device files or create a separate device file for it. Bootrom files will be unpacked in tftproot folder, and not in a firmware folder (like polycom/3.2.X). The reason for that is that a phone will look only in the root folder for the bootrom.

Migrating from 4.6

Please note that Polycom device files installed in 4.6 will be deleted after upgrade in 4.7. This is due to the fact in the new schema device files would go to a version specific folder, and sipXecs would have no way of knowing what version of firmware is deployed. Admins are advised to reupload the Polycom device files.

Automatic migration

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.

Manual migration

If somehow the automatic procedure fails for some of the phones (for some reason the phones could not have been rebooted) 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.

Bulk updgrading Polycom firmware on phones

The easiest way to do this is by using phone groups and a newly introduced setting "Group Firmware". Suppose you have a bunch of phones - say 50 SPIP 335s all with 3.2.6 firmware - you can place them in a group (or use existing groups the phones are in), click on a Polycom model (any model), edit the group and go to "Group Firmware". Here select the correct version in the Group Firmware > Firmware version update - 4.0.X and hit Apply. On Apply, all phones in the group will be saved. After that, you need to send profiles to the phones; 4.0.X configurations are created which phones will pick up on reboot.

It is important to note that you need to change "Firmware version update" and not the field "Firmware version" since the latter is not saved in the group settings and it is used to present correct settings based on the selected phone model. (For instance different models might have different set of codecs.)

In the scenario where you already have a group with phones that have different firmwares, create different groups for all the versions and then use the above procedure to update the phones firmware versions. You may delete the groups after doing that.

Applying a version to a group will update all the phones in the group with the specified version. You might not want to do that if you have phones with different versions in the group. If you do not want phones firmware to be updated just leave the Firmware version update field blank (select blank option).

If in a group there is a phone that does not support the chosen version, its version will not be changed.