[image1.jpeg]
On May 1, 2018, at 13:17, Anthony Holloway
<[email protected]<mailto:[email protected]>> wrote:
Thanks, now I want to watch that movie again. It's been a looong time.
I can agree that support is not black and white. Though, do consider the Cisco
Partner's perspective, when Customers ask for recommendations on what they
should be doing. Our responses should always be motivated by keeping them on
supported combinations of: configurations, hardware, and software.
And back to my original point, having firmware delivered via CUCM upgrades and
Device Packs is hurting that effort, because the collateral upgrading which is
occurring, is seldom what you want. I.e., Production is not ready for the new
firmware, or it's older than what you are already running.
Case in point: I have a customer right now with ones of thousands of phones,
looking to add support for the Webex Room Kit device, so we need a Device Pack,
but they are not ready to roll out a major firmware upgrade from 11.x to 12.x
on all of their 78/8800 series phones. Therefore, I have to now dance around
the firmware upgrade, in what should be an otherwise easy task of applying
support for just this specific device model.
I'd be curious to know how many people are actually delivering phone firmware
via Device Packs, versus CUCM upgrades, versus COP files, versus ZIPs.
For me, it goes like this:
1. CUCM Upgrades are for upgrading CUCM, I typically freeze the existing phone
firmware upgrades (and will do them pre- or post-upgrade of CUCM)
2. Device Packs are for adding support for newer models, I typically freeze the
existing phone firmware upgrades
3. COP Files are almost never used for upgrading phone firmware, they change
the device defaults, when my intention is never to upgrade 100% of a model
right from the start (pilot first)
*If COPs didn't change device defaults, I'd likely use these over ZIP
files. Do these restart TFTP automatically? I cannot recall.
4. ZIP Files are my preferred approach, because they are low risk because I can
easily control their distribution in the environment (like running a pilot
first)
On Mon, Apr 30, 2018 at 12:45 PM Ryan Ratliff (rratliff)
<[email protected]<mailto:[email protected]>> wrote:
Since Cisco already drops support for all firmware older than the most recent
firmware:
“You keep using that word, I do not think it means what you think it means”.
In all seriousness, and as the author of the document you quoted, there’s a
reason why the bulk of that document is dedicated to explaining the fact that
that the word “support” can mean many things, and even lists examples to
highlight this point.
I would also like to point out the fact that said document describes itself as
a “policy”, and policies don’t exist in a vacuum. They exist because there are
situations that require them to be applied, and it’s generally helpful when a
company you work with to publicly document whatever policy they are applying to
you. Equally important is that you are told exactly how and why that policy is
being applied to your situation.
All of that said my point is that the word “support” gets thrown around a lot
in the customer support business. We all should be certain to explain exactly
what version of the word we mean when using it, and if you find yourself on the
receiving end of a policy that limits some form of support for which you feel
you are entitled, you owe it to yourself and the other person to ask for
clarification.
Anyone that can’t provide that clarification or context is either being lazy or
doesn’t know what they are talking about.
-Ryan
On Apr 30, 2018, at 9:06 AM, Anthony Holloway
<[email protected]<mailto:[email protected]>> wrote:
I wish CUCM didn't ship with newer phone firmware.
Since Cisco already drops support for all firmware older than the most recent
firmware:
- For each IP Phone model, once Cisco releases a new firmware version, the
older versions are no longer supported.
- Cisco expects customers who encounter a problem on an older version of
firmware to test the latest firmware on a subset of phones in order to confirm
that the problem still exists.
Source:
http://www.cisco.com/c/en/us/support/docs/collaboration-endpoints/unified-ip-phone-7900-series/116684-technote-ipphone-00.html
And most people agree that you should upgrade firmware before a CUCM upgrade
anyway, just remove firmware from CUCM.
Not too mention it clutters up TFTP.
I also think that the firmware should be decoupled from the Device Packs. When
adding support for a single model phone, rarely am I also trying to upgrade
100% of the phones in the environment too.
On Sun, Apr 29, 2018 at 8:22 PM Charles Goldsmith
<[email protected]<mailto:[email protected]>> wrote:
Since the 8832 is a dual bank phone, shouldn't it have the old image on it in
the backup bank? Maybe hardcoding the old image on the phone configuration and
doing a reset will cause it to boot from it?
On Sun, Apr 29, 2018 at 7:06 PM Ryan Huff
<[email protected]<mailto:[email protected]>> wrote:
Sounds like the ole’ ‘step upgrade’ issue that plagued the 79xx series back in
the 8.x days ....
My guess is they don’t actually need RMA’ed, just the easiest way to deal with
it ....
I’d flash the phones and advertise an isolated tftp server to them with the
firmware load and XML bootstrap file. The phones aren’t working now, so
flashing them and then still not getting them to load right isn’t going to make
it any worse.
Use DNS in the DHCP scope in your isolation network with the TFTP server and
pcap/debug the DNS queries to see the bootstrap and load files it’s looking for.
In the 79xx series back in the day when I would perform this Lazarus trick for
some lucky customers; the bootstrap filename was XMLDefault.cnf.xml. Not sure
if it’s the same nowadays though.
Here is the Cisco doc on the procedure for the older stuff .... worth a shot
but not sure if it still works on the newer gear.
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200582-Update-Cisco-IP-Phone-Firmware-through-T.html
-Ryan-
On Apr 29, 2018, at 18:53, Jason Aarons (Americas)
<[email protected]<mailto:[email protected]>> wrote:
I have a customer with four 8832 conference room phones. Their CUCM was running
version 12.0.1 of the 8832 firmware. These phones shipped with version
12.0.1SR2. When they registered the first two phones they downgraded from
12.0.1SR2 to 12.0.1 and are now unusable. They sit on “Connecting” after
booting up. They do not get an IP address. You cannot set an IP address
manually. If you reset the phone it doesn’t fix it, nor does a factory
reset<https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8832/english/adminguide/cs88_b_conference-8832-admin-guide-cucm/cs88_b_conference-8832-admin-guide-cucm_chapter_01011.html>
allow the phone to revert to the firmware they shipped with. Cisco TAC says
they must be RMA’d. We upgraded CUCM to 12.0.1SR3 and the other two phones
upgraded fine from 12.0.1SR2 to 12.0.1SR3.
Does anyone have any ideas on what we could do to fix these phones other than
RMAing them?
Get Outlook for Android<https://aka.ms/ghei36>
This email and all contents are subject to the following disclaimer:
"http://www.dimensiondata.com/emaildisclaimer";<http://www.dimensiondata.com/Global/Policies/Pages/Email-Disclaimer.aspx>
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
