[FAQ] Supporting a mix of legacy SIP and UCS Phones on the same provisioning server

Polycom Employee & Community Manager

[FAQ] Supporting a mix of legacy SIP and UCS Phones on the same provisioning server

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.

 

2345-12375-001.bootrom.ld on the Provisioning Server is for example the name used for the Upgrader for a SoundPoint IP 335.

bootrom.ld is for on the Provisioning Server is for example the name used for the legacy SoundPoint IP 300 and SoundPoint IP500.

 

  

  • SoundPoint IP 300 and SoundPoint IP500 can only run as latest Software a SIP 2.1.x Release

  • SoundPoint IP 301, SoundPoint IP 501, SoundPoint IP 600, SoundPoint IP 601 and SoundStation IP 4000 can only run as latest Software a SIP 3.1.x Release

  • SoundPoint IP 430 can only run as latest Software a SIP 3.2.x Release

  • SoundPoint IP 320 and SoundPoint IP 330 can only run as latest Software a UCS 3.3.x Release

  • SoundPoint IP 450, SoundPoint IP 550, SoundPoint IP 560, SoundPoint IP 650, SoundPoint IP 670, SoundStation IP 5000, SoundStation IP 6000, SoundStation IP 7000, SoundStation DUO, VVX1500 and VVX500 can run a UCS 4.0.x Release

  • SoundPoint IP 450, SoundPoint IP 550, SoundPoint IP 560, SoundPoint IP 650, SoundPoint IP 670, SoundStation IP 5000, SoundStation DUO, VVX500,VVX600,VVX300/310 and VVX400/410 can run a compatible UCS 4.1.x Release

  • VVX500,VVX600,VVX300/ VVX310 and VVX400/ VVX410 can run a compatible UCS 5.0.x Release

 

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.

 

Example SPIP501:

 

<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:

 

CONFIG_FILES=""

Changing this into:

 

CONFIG_FILES="config[PHONE_MAC_ADDRESS].cfg"

 

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:

 

  • Download SoundPoint IP and SoundStation IP SIP 3.1.8 Legacy [Split]
  • Download SoundPoint IP/SoundStation IP BootROM 4.1.2
  • Download Polycom UC Software 4.1.4 split for Polycom VVX300, VVX310, VVX400 and VVX410

  • Have an individual config<mac>.cfg (this needs to be manually created or use some sort of selfmade script)

  • Modify the 000000000000.cfg as shown above

  • Boot the VVX 300 phones would only load their individual configuration and the legacy SPIP501 would load their config<mac>.cfg, phone1_318.cfg and sip_318.cfg
Please be aware:

The purpose of these forums is to allow community members collaborate and help each other.
Questions posted here do not follow Polycom’s SLA guidelines.
If you require assistance from Polycom technical support, please open a
web service request or call us .

The above is necessary in order to track issue internally within Polycom.

You are welcome to post more questions or configuration or logs for other community members to look at but if your issue requires a fix via Polycom you must go via the official support structure.

Please ensure you always check the VoIP , Video Endpoint , Skype for Business , PSTN or RPM FAQ's

Please remember, if you see a post that helped you , and it answers your question, please mark it as an "Accept as Solution".

This forum reply or post is based upon my personal experience and does not reflect the opinion or view of my employer.
Polycom employee participation within this community is not mandatory and any post or FAQ article provided by myself is done either during my working hours or outside working hours, in my private time, and may be answered on weekends, bank holidays or personal holidays.
Message 1 of 1