Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 16 Next »

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

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, 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.

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

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. 

PolycomPhone.java
  @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.

It is recommended that admins take some steps to "migrate" their Polycom phones to 4.6.1 new system. (Note that by this we don't mean upgrade the phones to a different firmware version/bootrom.)

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 - 3.2.X and hit Apply. On Apply, all phones in the group will be saved. It is not necessary to send profiles to the phones, but next time you have to do this, the phones will pick up the correct configurations.

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.
  • No labels