Page Comparison

...

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. A manual migrating procedure is described below, since sipXecs has no way of automatically knowing what specific firmware version a phone hasSince 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.

...

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

When upgrading from 4.6 admins can leave the device files in place just fine and the system and its defined phones will continue to function just like before. Even when profiles are sent to a phone, although [MAC].cfg will be configured with the new path to the sip.ld file, if the phone will not find it it will just use the existing SIP application.

In 4.6 all Polycom models have by default a hardcoded "2.0" version. In 4.6.1, we have kept this version in code however it has no corresponding support in configuration files or firmware. However the configuration files are by default created after 3.2 image as you can see from the following if-else block. 

  @Override
    public void setDeviceVersion(DeviceVersion version) {
        super.setDeviceVersion(version);
        DeviceVersion myVersion = getDeviceVersion();
        if (myVersion == PolycomModel.VER_4_0_X) {
            getModel().setSettingsFile("phone-40.xml");
            getModel().setLineSettingsFile("line-40.xml");
            getModel().setStaticProfileFilenames(new String[]{});
        } else if (myVersion == PolycomModel.VER_3_1_X){
            getModel().setSettingsFile("phone.xml");
            getModel().setLineSettingsFile("line.xml");
            getModel().setStaticProfileFilenames(new String[]{
                "polycom_phone1_3.1.X.cfg",
                "polycom_sip_3.1.X.cfg"});
        } else {
            //we need to explicitly define these here otherwise changing versions will not work
            getModel().setSettingsFile("phone-32.xml");
            getModel().setLineSettingsFile("line-32.xml");
            getModel().setStaticProfileFilenames(new String[]{
                    "polycom_phone1.cfg", "polycom_sip.cfg"});
        }
    }

Thus, even after upgrade, if profiles are sent to a phone (without previously saving the phone) the phone's [MAC].cfg will be configured to look for the polycom/2.0/sip.ld which does not exist, so the phone will use its existing SIP application. But config files will be generated for 3.2. This might be a problem if the phone has a different firmware version.

...

Note
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 - 34.20.X and hit Apply. On Apply, all phones in the group will be saved. It is not necessary After that, you need to send profiles to the phones, but next time you have to do this, the ; 4.0.X configurations are created which phones will pick up the correct configurationson reboot.

...