12-01-2010 01:34 PM - edited 03-16-2019 02:13 AM
I am currently running Cisco UCM 7.1 and I would like to upgrade to 8.0. Is there any hardware upgrade needed on the voice h323 gateways? (Cisco ISRs 2800 platform, most of them running 256 MB of RAM - c2800nm-advipservicesk9-mz.124-20.T2.bin)
Thanks,
marramix01
Solved! Go to Solution.
12-01-2010 02:11 PM
You may receive different opinions here, but I tend to look at IOS code upgrades in conjunction with CUCM as optional in most cases. Which is to say that typically you aren't forced to upgrade voice gateways to maintain interoperability. Areas where this general rule may fall short is when something significant changes in the communication protocol for CUCM or when leveraging SRST.
In regards to protocol changes, there have been code releases where CUCM is adding functionality on its end which may cause one to upgrade the voice gateway to take advantage of the new functionality. In some cases, it is possible that CUCM changes how it handles some protocol function and that could change either default configs or introduce an interop problem on the gateway. In my experience, it is actually uncommon to be forced to do a gateway upgrade based purely on protocol compatibility. For my customers that use MGCP, Q.SIG, T.38 and similar features, I like to look at the CUCM release notes and SRNDs to see if anything substantial has changed. I also tend to research a little deeper when a customer is using SIP as I find that changes are rampant with this protocol implementation on Cisco gear. For H.323, I can't recall being forced to do an upgrade on the voice gateway. Maybe when call preservation features on H.323 were first being introduced, but that is some time ago and I can't think of specific example.
Now, with SRST enabled gateways I find that an upgrade on the voice gateway is a more common pre-requisite. This isn't necessarily a direct result of the CUCM code upgrade. Actually, it is typically that customers are moving to a later CUCM release to take advantages of new device features/capabilities. When going to CUCM to get access to new devices (e.g. phones) you will most likely need to have parity in SRST and therefore face an upgrade on the voice gateway. There are also feature enhancements to pay attention to. For example, enhancements in SRST for SIP devices or secured devices. Again, not necessarily a direct result of the CUCM release per se.
All this being said, whenever we (NetCraftsmen) approach an upgrade we perform an analysis of the voice gateway code set. Our analysis is heavily impacted by the features the customer relies on to do their day-to-day work. We look for obvious enhancements or changes in how CUCM communicates with SIP, MGCP, and H.323 gateways. We search the bug toolkit for defects in the new CUCM code related to the signaling protocol of choice. Finally, we have a validation plan which tests out the target CUCM code with the target voice gateway code before going to production. The target voice gateway code is usually the same as the existing code.
I know this isn't a definitive answer for you, because in reality the only answer that makes sense is: "it depends". All I can say it is unlikely that you would be forced to do an upgrade but that you should still continue your research (e.g. read release notes, read the SRNDs) and you should definitely test/validate interoperability.
HTH.
Regareds,
Bill
Please remember to rate helpful responses and identify
12-01-2010 02:11 PM
You may receive different opinions here, but I tend to look at IOS code upgrades in conjunction with CUCM as optional in most cases. Which is to say that typically you aren't forced to upgrade voice gateways to maintain interoperability. Areas where this general rule may fall short is when something significant changes in the communication protocol for CUCM or when leveraging SRST.
In regards to protocol changes, there have been code releases where CUCM is adding functionality on its end which may cause one to upgrade the voice gateway to take advantage of the new functionality. In some cases, it is possible that CUCM changes how it handles some protocol function and that could change either default configs or introduce an interop problem on the gateway. In my experience, it is actually uncommon to be forced to do a gateway upgrade based purely on protocol compatibility. For my customers that use MGCP, Q.SIG, T.38 and similar features, I like to look at the CUCM release notes and SRNDs to see if anything substantial has changed. I also tend to research a little deeper when a customer is using SIP as I find that changes are rampant with this protocol implementation on Cisco gear. For H.323, I can't recall being forced to do an upgrade on the voice gateway. Maybe when call preservation features on H.323 were first being introduced, but that is some time ago and I can't think of specific example.
Now, with SRST enabled gateways I find that an upgrade on the voice gateway is a more common pre-requisite. This isn't necessarily a direct result of the CUCM code upgrade. Actually, it is typically that customers are moving to a later CUCM release to take advantages of new device features/capabilities. When going to CUCM to get access to new devices (e.g. phones) you will most likely need to have parity in SRST and therefore face an upgrade on the voice gateway. There are also feature enhancements to pay attention to. For example, enhancements in SRST for SIP devices or secured devices. Again, not necessarily a direct result of the CUCM release per se.
All this being said, whenever we (NetCraftsmen) approach an upgrade we perform an analysis of the voice gateway code set. Our analysis is heavily impacted by the features the customer relies on to do their day-to-day work. We look for obvious enhancements or changes in how CUCM communicates with SIP, MGCP, and H.323 gateways. We search the bug toolkit for defects in the new CUCM code related to the signaling protocol of choice. Finally, we have a validation plan which tests out the target CUCM code with the target voice gateway code before going to production. The target voice gateway code is usually the same as the existing code.
I know this isn't a definitive answer for you, because in reality the only answer that makes sense is: "it depends". All I can say it is unlikely that you would be forced to do an upgrade but that you should still continue your research (e.g. read release notes, read the SRNDs) and you should definitely test/validate interoperability.
HTH.
Regareds,
Bill
Please remember to rate helpful responses and identify
12-02-2010 05:37 AM
Thank you for taking the time to answer my question. I think I can run with this.
Marramix01
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