Supporting a mix of different Software revisions in an environment that holds both legacy Phones running SIP 2.2.x, SIP 3.1.x SIP 3.2.x and UCS 3.3.x and UCS 4.x.x can be easily archived by following a few simple guidelines.
Polycom supplies a document => here <= that describes this scenario in detail.
The important part is using the correct files and configurations.
The individual BootROMs or Upgraders should be available in the root directory.
Since legacy phones are not compatible with BootROM versions after their last supported release, Polycom recommends that split images be used for maintenance and upgrade of BootROM releases.
Since you cannot rename the BootROM release files like the SIP release files the relevant <PHONE_PART_NUMBER>-bootrom.ld files will need to be placed on the provisioning server for each phone model.
The best way to do this is to download the most recent patch release for every BootROM version.
If you download and unzip the files in chronological order, starting from the oldest version up the latest 4.0.x, the newer files will overwrite the older ones.
The newer BootROM package will only contain files for supported versions, so if a newer version does not support a legacy platform, the older BootROM file will stay intact.
This way you can ensure the BootROM for each phone is updated to the most recent supported version.
A 2345-12375-001.bootrom.ld on the Provisioning Server is for example the name used for the Upgrader for a SoundPoint IP 335.
A bootrom.ld is for on the Provisioning Server is for example the name used for the legacy SoundPoint IP 300 and SoundPoint IP500.
Each downloaded Software Release (Polycom Support recommends the SPLIT download) contains a 000000000000.cfg file.
This Master Configuration files already caters for the above phones and their restriction regarding running the latest available Software.
Note: This file is read only and the file attributes need to be changed in order to modify the file!
<?xml version="1.0" standalone="yes"?> <!-- Default Master SIP Configuration File--> <!-- For information on configuring Polycom VoIP phones please refer to the --> <!-- Configuration File Management white paper available from: --> <!-- http://www.polycom.com/common/documents/whitepapers/configuration_file_management_on_soundpoint_ip_p... --> <!-- $RCSfile$ $Revision: 135829 $ --> <APPLICATION APP_FILE_PATH="sip.ld" CONFIG_FILES="" MISC_FILES="" LOG_FILE_DIRECTORY="" OVERRIDES_DIRECTORY="" CONTACTS_DIRECTORY="" LICENSE_DIRECTORY="" USER_PROFILES_DIRECTORY="" CALL_LISTS_DIRECTORY=""> <APPLICATION_SPIP300 APP_FILE_PATH_SPIP300="sip_213.ld" CONFIG_FILES_SPIP300="phone1_213.cfg, sip_213.cfg"/> <APPLICATION_SPIP500 APP_FILE_PATH_SPIP500="sip_213.ld" CONFIG_FILES_SPIP500="phone1_213.cfg, sip_213.cfg"/> <APPLICATION_SPIP301 APP_FILE_PATH_SPIP301="sip_318.ld" CONFIG_FILES_SPIP301="phone1_318.cfg, sip_318.cfg"/> <APPLICATION_SPIP320 APP_FILE_PATH_SPIP320="sip_334.ld" CONFIG_FILES_SPIP320=""/> <APPLICATION_SPIP330 APP_FILE_PATH_SPIP330="sip_334.ld" CONFIG_FILES_SPIP330=""/> <APPLICATION_SPIP430 APP_FILE_PATH_SPIP430="sip_327.ld" CONFIG_FILES_SPIP430="phone1_327.cfg, sip_327.cfg"/> <APPLICATION_SPIP501 APP_FILE_PATH_SPIP501="sip_318.ld" CONFIG_FILES_SPIP501="phone1_318.cfg, sip_318.cfg"/> <APPLICATION_SPIP600 APP_FILE_PATH_SPIP600="sip_318.ld" CONFIG_FILES_SPIP600="phone1_318.cfg, sip_318.cfg"/> <APPLICATION_SPIP601 APP_FILE_PATH_SPIP601="sip_318.ld" CONFIG_FILES_SPIP601="phone1_318.cfg, sip_318.cfg"/> <APPLICATION_SPIP670 APP_FILE_PATH_SPIP670="sip_403.ld" CONFIG_FILES_SPIP670=""/> <APPLICATION_SSIP4000 APP_FILE_PATH_SSIP4000="sip_318.ld" CONFIG_FILES_SSIP4000="phone1_318.cfg, sip_318.cfg"/> <APPLICATION_SSIP7000 APP_FILE_PATH_SSIP7000="sip_403.ld" CONFIG_FILES_SSIP7000=""/> </APPLICATION>
Above clearly shows how the different phone types utilize the substitutions method in order to load their own sip.ld.
The sip.ld that comes with a SIP 3.1.8 download for example has already been renamed into sip_318.ld in order to separate the different SIP / UCS Software Versions.
The usual sip.cfg and phone1.cfg also already has been renamed to sip_318.cfg and phone1_318.cfg.
If a customer is already using their own sip.cfg and phone1.cfg before upgrading to a later SIP Version the support team recommends to utilize the sip_318.cfg and phone1_318.cfg provided with the latest download and manually changing the relevant parameters.
This ensures that the SIP Version uses the optimized version of values coming with this release rather than attempting to load old and possible outdated variables.
<APPLICATION_SPIP501 APP_FILE_PATH_SPIP501="sip_318.ld" CONFIG_FILES_SPIP501="phone1_318.cfg, sip_318.cfg"/>
So the phone would attempt to load the sip_318.ld software, the phone1_318.cfg and the sip_318.cfg.
If a individual file per phone would be available we would now use the substitution.
Example name could be config0004f2123456.cfg. If such file would be available for each phone the following could be used:
<APPLICATION_SPIP501 APP_FILE_PATH_SPIP501="sip_318.ld" CONFIG_FILES_SPIP501="config[PHONE_MAC_ADDRESS].cfg,phone1_318.cfg, sip_318.cfg"/>
Using the config[PHONE_MAC_ADDRESS].cfg string in this case would cause each individual phone that fits into the 501 category to automatically substitute its own MAC Address and therefore load the individual configuration before attempting to load the other 2 files.
In order to provision all other newer non legacy phones the follow part in the 000000000000.cfg would be used:
Changing this into:
The APP_FILE_PATH_ can in addition be used to specify additional Software that should be loaded by a group of phones. The substitutions method can be used to load individual configurations on a per phone basis.
UCS 3.3.x and UCS 4.x.x do no longer use a sip.cfg or a phone1.cfg and only need to load their individual settings or global settings. Both can be archived utilizing the substitutions method.
Any issues whilst upgrading phones or loading their Software should be followed up by consulting their individual log files as they will contain the reason for a failed upgrade.
Example to support SPIP501 and VVX300 on one provisioning server: