...
| Note | ||
|---|---|---|
| ||
In 4.6.0 and earlier releases of sipXecs some phones were defined as paired models, since they had the same configuration. In 4.6.0 Update 1 the models have been split. On migration to 4.6.0 Update 1, 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):
|
Before you update
| Note |
|---|
Here are some things you need to know before upgrading 4.6.0 to 4.6.0 Update 1. All of them will be explained in more detail in this wiki page
|
Installing firmware
| 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. |
...
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.0 Update 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.
...
Automatic migration
After updating to 4.6.0 Update 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.
...
In order to upgrade a phone to 4.0.X firmware you must deploy a special bootrom and, of course, the 4.0 firmware. The special bootrom is called Upgrader, and the latest 4.0 firmware is 4.0.3F (use split and not combined!). You can download them from Polycom site:
...
Downgrading is currently not a supported procedure on sipXecs 4.6.0. It can be done and the procedure is documented on Polycom site. Basically, in order to downgrade a phone from 4.0 to 3.2 one must deploy another special bootrom SIP application called Downgrader and a which will downgrade the phone to 3.3.5 firmware revision, and only after that deploy a 3.2 firmware.
You can follow these steps:
- Download the downgrader from Polycom site. You can find it here: http://support.polycom.com/PolycomService/support/us/support/voice/polycom_uc/polycom_uc_software_support_center.html
- Deactivate all Polycom device files.
- Create a new Polycom "Device files" and upload the Upgrader on the SIP Application (zip) field and under 4.0.X firmware (we assume all phones needed to be downgraded are at 4.0.X firmware revision). (Leave the Bootrom field blank.) (Use common sense, if phone is actually 3.2.X in sipXconfig database, upload it under 3.2.X firmware.)
- Reboot phones. NOTE: if you have phones with 4.0 firmware which you do not want to downgrade, make sure you do not reboot them.
- Phones will pickup the new bootrom and firmare (3.3.5).
- Create another Device files (or activate it if you already have one) with 3.2 firmware. I used 4.3.1 bootrom, and 3.2.6 firmware. Make sure you set the correct firmware version (3.2.X).
- Change the phone(s) firmware version (either from phone or from group).
- Send profiles to the phone(s).
- Phone(s) will reboot and pickup the bootrom and firmware.
NOTE: phones might reboot a couple of times after it gets new bootrom / SIP app / configuration. I don't know exactly if there is a pattern, but just keep this in mind.
Important
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. |
Auto provisioning a phone out of the box
An out of the box phone (or any phone that has not been configured in sipXecs), will contact the server to download the configuration file, and, if since this is not found will download the Polycom master configuration file (000000000000.cfg). In this file the default firmware revision for Polycom phones is 4.0. Thus phones will try to download the sip.ld file corresponding to that revision.
| Code Block |
|---|
<APPLICATION
APP_FILE_PATH="polycom/4.0.X/sip.ld"
...
</APPLICATION> |
For this, administrators must make sure that they have a 4.0 revision deployed together with a compatible bootrom.
Phones that are not compatible with 4.0 revision are defined in specific sections of the master configuration file.
| Phone | Revision |
|---|---|
| SPIP 300 | 3.1 |
| SPIP 301 | 3.1 |
| SPIP 500 | 3.1 |
| SPIP 501 | 3.1 |
| SPIP 4000 | 3.1 |
| SPIP 600 | 3.1 |
| SPIP 601 | 3.1 |
| VVX 600 | 4.1 |
| Info |
|---|
Above notes apply also for a phone that has been formated. |
Common problems (and solutions)
...