7962 and 8945 phone at firmware 9.4.2 can no longer access web interface of the phone

[kbyrd]

I'm preparing for a upgrade and rehost of a CUCM 8.6 on a MCS7925 to 10.5 on UCS/BE7000.

To make the migration easier, I'm upgrading the firmware on the CUCM 8.6 system to 9.4.2 for 8945, 7942, and 7962 IP phones from v9.2.1 and 9.2.2  prior to migration.

I could access the phone's web interface with no problem before the upgrade but cannot after the upgrade. The phone works fine.

Specifically for the 8945 phone, I had to upgrade through 9.3.4 to get to 9.4.2. At 9.3.4, I could still access the 8945 web interface. At 9.4.2, I could not.

This sounds like a security setting, but I have verified that the CUCM device parameter for web access of the phone is enabled.

Any help is appreciated.

[Manish Gogna · Accepted solution]

Although i do not see a bug for this specific behavior i did find a couple of customers reporting this issue to TAC. While one downgraded the firmware as a workaround the other one was provided an ES version of firmware to fix it. You may contact TAC for a resolution.

Manish

- Do rate helpful posts -

[Albert Paul Raj Vathamanickam]

Hi,

Did you raise a TAC case for this? Or did you find a resolution? I'm facing the same issue on 8945 phone when i upgraded to 9.4.2.. Is this a bug?

Regards,

Albert

[Aman Soi]

Hi Albert,

Just have a look into bug .

Enable web access and SSH for new phone for 8945

CSCuu51697

Description

Symptom:
Enhancement request for enabling web access and SSH of new 8945 phone
When 8945 is new and never register to CUCM web access and SSH is disable by default
We would like to enable web access and SSH for the phone when the phone can't register with CUCM

Conditions:
New 8945 phones

Workaround:
no workaround

Known Affected Releases:

(2)

9.4(2)

9.4(2)SR2

[kbyrd]

Based on the bug notes, that does not appear to be my issue. This appears to be an enhancement so that the default behavior of a new 8945 phone is to have web and ssh enabled by default.

In my case, the parameters of the currently registered (not new) 8945 are set for web enabled.

I will update this discussion after I am able to get the dev-pack installed.

[kbyrd]

Update: For prep'ing to move these phones (including the 8945) to a new v10.5 cluster (upgrade and rehost), I had to change the Enterprise Parameter Prepare Cluster for Rollback to pre 8.0 to TRUE. This required me to restart the Trust Verification Service (TVS) on both nodes, restart the TFTP service on all nodes, and reset all phones.

Before I did this, the web service on the phone wouldn't respond and the clock on the 8945 was off. Now everything is working.

I don't know what fixed the issue (perhaps it was the TFTP service restart), but now everything is looking good.

Lastly, the prior load on the 8945s (SCCP894x.9-2-2-0) had a serious audio cut-thru issue where it literally took a couple of seconds after answering a ringing 8945 before the audio would start. That has been corrected as well.

[Aman Soi]

thanks for update[+5]

regds,

aman

[kbyrd]

I have TAC case 636718995. The engineer suggested I should have first installed cmterm-devicepack8.6.2.26169-1.cop.sgn before I upgraded. I provided the engineer with requested configuration files (SEP<mac>.cnf.xml) for a 7942 and a 8945 from CUCM v8.6 for analysis. I have not yet heard back.

I'm guessing that is the issue. On the new CUCM v10.5, I am able to access the GUI for the 7942 running the same code. I have not been able to coordinate with my customer the installation of cmterm-devicepack8.6.2.26169-1.cop.sgn on his production v8.6 system.

[Albert Paul Raj Vathamanickam]

What device package file have you installed on the new CUCM v10.5? My customer is on v10.5 but we're seeing this web access issue on the the 8945 phones.

[kbyrd]

I installed this: UCSInstall_UCOS_10.5.2.12901-1.sgn.iso on their new system, but I have not had a chance to move over the 8945s.

[Albert Paul Raj Vathamanickam]

Thanks. Do let me know the outcome of the TAC's investigation.. I would like to know if installing the devicepack resolved the issue.

Regards,

Albert