[cisco-voip] 8832s

Tue May 1 15:34:48 EDT 2018

I can't believe there's still no syncing of TFTP/MOH Files or at least
making it the default option.  Uploading things to every node
over-complicates things.  And TFTP File Management has no bulk upload which
is super annoying when I rebuild subscribers on an upgrade.  I keep meaning
to make a script for that bulk TFTP upload.

There definitely needs to be some overhaul of phone firmware management.

We'll probably just see the phones start reaching out to the Webex cloud
nightly to update their phone firmware as we further this cloud transition.

We have to make sure this stuff doesn't get too easy for the customers and
kill off all our jobs too :P

On Tue, May 1, 2018 at 3:25 PM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> "With upgrades, some phones begin upgrading before I can switch this back
> though."
>
> I've had this happen more times than I'm comfortable admitting, and
> especially, I've already set the expectation that phones will not upgrade.
>
> Installing the COP and then changing the Device Defaults is six of one and
> a half-dozen of the other, when compared to uploading the few files in the
> ZIP, and not touching the defaults.  To each his own, of course.
>
> "I think some customers would just never update device firmware if it
> didn't force it on them though."
>
> There are people still running 2800 ISRs, MCS, CUCM 7.x, and even 7940s.
> Is firmware really the place to start forcing people to modernize?  I think
> it would be best to let the customer choose, unless they move to a cloud
> based solution.
>
> On Tue, May 1, 2018 at 2:13 PM Brian Meade <bmeade90 at vt.edu> wrote:
>
>> I think we've got to remember a lot of different types of customers use
>> CUCM.
>>
>> I've got some customers that need the ease of use with the COP file
>> updating the device defaults automatically.  I actually use this method
>> most of the time as well and just revert the device default change before
>> restarting TFTP and resetting any phones.
>>
>> The device packs and upgrades are a bit annoying to me with it changing
>> all my phone firmware.  I usually Bulk Export then Device Defaults and
>> re-import after to avoid this.  With upgrades, some phones begin upgrading
>> before I can switch this back though.  I think some customers would just
>> never update device firmware if it didn't force it on them though.
>>
>> On Tue, May 1, 2018 at 1:04 PM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> 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) <
>>> rratliff at cisco.com> 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 <
>>>> avholloway+cisco-voip at gmail.com> 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 <wokka at justfamily.org>
>>>> 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 <ryanhuff at outlook.com>
>>>>> 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) <
>>>>>> jason.aarons at dimensiondata.com> 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
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180501/f0f32bdf/attachment.html>