...
| 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
| Warning | ||
|---|---|---|
| ||
Please note that Polycom device files installed in 4.6.0 (be it active or inactive) will be deleted on upgrade. Admins are advised to re-add the device files for the wanted firmware. |
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.
...
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.
| Note | ||
|---|---|---|
| ||
Please note that Polycom device files installed in 4.6.0 (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
| Notetip | ||
|---|---|---|
| ||
| 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.0
| Notewarning |
|---|
Please note that Polycom device files installed in 4.6.0 will be deleted after upgrade in 4.6.1. 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.6.1 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 | ||
|---|---|---|
| ||
|
Manual migration
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.
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
...
| Note |
|---|
| 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). |
...
| Note |
|---|
| You must change the phone version to 4.0.X in in order for a phone to be upgraded. Failing to do so might render the phone unable to start due to the fact it will pickup the new bootrom and try to find a suitable sip.ld in a folder other than 4.0.X, however any other sip.ld is incompatible with the phone new bootrom. you might get "Image is incompatible with the phone" error on the phone. |
...
If you have a phone compatible with 4.0 but you DO NOT WANT TO UPGRADE it to 4.0 and keep it to 3.2 (or 3.1) 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.
...
| Tip |
|---|
Upload as many bootroms as you like, but do not keep any of those deployed except when you are upgrading a phone or a group of phones. This will prevent unwanted phone upgrades. |
Common problems (and solutions)
- Problem: Phone keeps rebooting and displays "Misc file error"
Solution: On phones page choose correct model, installed firmware, apply changes and send profiles - Problem: Phone keeps rebooting and displays "Image is incompatible with the phone"
Solution: Bootrom and sip.ld are incompatible. Most likely Upgrader is deployed as bootrom, and phone is set to 3.1.X or 3.2.X. On phone's page choose 4.0.X and reboot the phone. Make sure a 4.0 image is deployed (active).