05-03-2010 02:42 PM - edited 03-15-2019 10:36 PM
When a cucm is upgraded, and phones re register back with cucm (newer version) , do the phone loads get updated before registering ? would that cause delay in restore service?
Thanks...
Solved! Go to Solution.
05-03-2010 02:45 PM
If there is a firmware version change (typical), yes. Longer outage,
yes.
Sent from my iPhone
On May 3, 2010, at 5:43 PM, gmcleveney
05-03-2010 03:06 PM
Typically a CUCM upgrade will include a change in the firmware. Unless you modify the Device Defaults after the upgrade your phones will receive the new firmware load information when they pull the configuration file from the TFTP server. If the new firmware load version does not match the running version on the phone, then the phone will upgrade the firmware before registering to the cluster. Depending on the size of your cluster, the size of the firmware, the distribution of phones across the LAN/WAN, etc. that could lead to an extended outage when doing the upgrade.
We recommend that you consider one of the following approaches.
First, determine if the existing firmware is compatible with the new CUCM version and features. If so, then if you are not experiencing issues with the new firmware there is no need to upgrade. In this instance, when you do your upgrade you will want to modify the Device Defaults before you reset the phones.
Second option. It is more likely that you will find you want to upgrade the firmware of the phones (and even more likely you will want something later than what comes with the CUCM upgrade by default). In these cases you will want to pick firmware that is compatible with the current release of CUCM and the target release. Then schedule a change window in advance of your CUCM upgrade where you upgrade the firmware on the phones. It is definitely a good idea to separate phone firmware upgrade from CUCM upgrades. Primarily because you will already have enough to deal with and you want to minimize overall risk and exposure to faults. Divide and conquer being the mantra.
In both of these options, you may find that you need to either trick the phones into not upgrading firmware or block access. Blocking access can take the form of using a network ACL that blocks access to your TFTP servers. It can also take the form of disabling/stopping the TFTP services on the TFTP servers. This really becomes an issue if the server that is your TFTP host and your publisher also is the primary call processing agent for phones. One approach that works for me is to use BAT to force the phones to use a specific firmware version (the one they are already running). This way, when you upgrade the CUCM the phones will disregard the device defaults and use their locally programmed firmware version instead. Then, once the dust settles on your upgrade, use BAT to remove the device-specific firmware load ID. This puts you back to the status quo of using the Device Defaults which is operationally preferred.
HTH.
Regards,
Bill
Please remember to rate helpful posts.
Please remember to rate helpful responses and identify
05-03-2010 04:03 PM
Yes. They will upgrade because when they fallback to CUCM, they will
need to reestablish a full TCP connection and will start at the
beginning of the registration process which is to ask for TFTP. At
that point, phones will begin to loaf the new firmware.
Hailey
Sent from my iPhone when I could be having fun but Im helping
others Please rate helpful posts!
On May 3, 2010, at 6:30 PM, gmcleveney
05-03-2010 02:45 PM
If there is a firmware version change (typical), yes. Longer outage,
yes.
Sent from my iPhone
On May 3, 2010, at 5:43 PM, gmcleveney
05-03-2010 03:06 PM
Typically a CUCM upgrade will include a change in the firmware. Unless you modify the Device Defaults after the upgrade your phones will receive the new firmware load information when they pull the configuration file from the TFTP server. If the new firmware load version does not match the running version on the phone, then the phone will upgrade the firmware before registering to the cluster. Depending on the size of your cluster, the size of the firmware, the distribution of phones across the LAN/WAN, etc. that could lead to an extended outage when doing the upgrade.
We recommend that you consider one of the following approaches.
First, determine if the existing firmware is compatible with the new CUCM version and features. If so, then if you are not experiencing issues with the new firmware there is no need to upgrade. In this instance, when you do your upgrade you will want to modify the Device Defaults before you reset the phones.
Second option. It is more likely that you will find you want to upgrade the firmware of the phones (and even more likely you will want something later than what comes with the CUCM upgrade by default). In these cases you will want to pick firmware that is compatible with the current release of CUCM and the target release. Then schedule a change window in advance of your CUCM upgrade where you upgrade the firmware on the phones. It is definitely a good idea to separate phone firmware upgrade from CUCM upgrades. Primarily because you will already have enough to deal with and you want to minimize overall risk and exposure to faults. Divide and conquer being the mantra.
In both of these options, you may find that you need to either trick the phones into not upgrading firmware or block access. Blocking access can take the form of using a network ACL that blocks access to your TFTP servers. It can also take the form of disabling/stopping the TFTP services on the TFTP servers. This really becomes an issue if the server that is your TFTP host and your publisher also is the primary call processing agent for phones. One approach that works for me is to use BAT to force the phones to use a specific firmware version (the one they are already running). This way, when you upgrade the CUCM the phones will disregard the device defaults and use their locally programmed firmware version instead. Then, once the dust settles on your upgrade, use BAT to remove the device-specific firmware load ID. This puts you back to the status quo of using the Device Defaults which is operationally preferred.
HTH.
Regards,
Bill
Please remember to rate helpful posts.
Please remember to rate helpful responses and identify
05-03-2010 03:30 PM
THANK YOU.
When phones fallback to srst and re register back to cucm, even without a reset of the phones the firmware will update(since cucm is newer version) correct?
05-03-2010 03:34 PM
Assuming that either the Device Defaults or the device itself have a different load ID specified than what is running on the actual IP phone, yes it will update.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
05-03-2010 04:03 PM
Yes. They will upgrade because when they fallback to CUCM, they will
need to reestablish a full TCP connection and will start at the
beginning of the registration process which is to ask for TFTP. At
that point, phones will begin to loaf the new firmware.
Hailey
Sent from my iPhone when I could be having fun but Im helping
others Please rate helpful posts!
On May 3, 2010, at 6:30 PM, gmcleveney
05-03-2010 07:15 PM
THANK YOU!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide