[cisco-voip] 8832s

Tue May 1 15:13:52 EDT 2018

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/d2dd8cfe/attachment.html>