Problem with 7942 Phone CUCM 7.1.3

[matthewlogan46]

Hi,

I have a problem with a 7962 phone, I have changed the number of  line but this line not show the change, I have restarted the phone and the line always show the same extension number. With the Speed Dial configuration, I have the same problem.

I sent the phone to factory settings, but the same problem. I restarted the TFTP service in the cluster, and the problem persist.

The call manager are System version: 7.1.3.30000-1 and the firmware of the phone is SCCP42.9-3s

Any ideas?

[Chris Deren]

What did you change?

Did you change the phone button template?

What is showing in CUCM pages under the Line section? Can you post a screen shot?

Chris

[matthewlogan46]

Hi Chris,

I change the extension number, and change the phone button template, but this is not reflected in the 7962 telephone.

I attached the image of the line CUCM and the phone screen.

[Chris Deren]

Can you post a screen shot of the phone button template you are using?

Chris

[matthewlogan46]

Hi Cris,

Well, the phone was initially configured with 2 lines, 1 and 2 intercom BLF, phone buttton then change the template, I am by default. after changing the phone button template the phone does not recognize changes!.

Regards.

[Jaime Valencia]

Have you tried recreating the TFTP files?

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

[Matthew Loggan]

Hi Jaime,

Thanks for your response, I really do not understand what you mean much to recreate the TFTP file.

I have removed the phone and the line, then I restarted the TFTP server in the cluster, then I re-created the phone and the problem persists.

If you can give me more background on how to recreate the file TFTP I'd appreciate.

Regards.

[will.alvord]

Matthew,

I realize that you already factory reset the phone, but can you confirm from the phone that the tftp server is correct (settings, network config, ipv4, tftp server 1/2)?  If changes within UCM are not reflected on a device, that's the 1st thing I'd check.  Next, I'd check the status messages for any tftp related errors.

will

[William Bell]

In addition to Will's guidance (+5 W.)  (do verify the basics first) here is a thought. I may be off base on this one but I do recall hitting a similar problem on a 7.1 system a while ago. The issue was related to the DBL Notify messaging to the TFTP service. IIRC, I verified the behavior by doing a Detailed trace on TFTP and DBL monitor. I then looked at the TFTP traces and the latest "dbnotify_ctftp.log" file in the /cm/trace/dbl/sdi/ctftp/ folder.

In a healthy system you should see the following:

1. Device config file is available  (this isn't in the trace but you can do a "file list tftp " to check for the config file.

2. TFTP trace will show the actual creation of the device

3. DBL trace will show a line where it told the TFTP service to create the file

Your phone is behaving as if the config file is not there and it is "rolling back" to the last known good config.

If you see a config file in the TFTP repository for the phone, then I would pull it down to your workstation (you can use a tftp client to do that) and check the contents to see if things line up to expectations.

With the issue I ran into, the DBL service was simply not notifying the TFTP service that something has changed. Bouncing the DBL Monitor service fixed the issue. There were a couple of bugs related to this issue but I don't have those handy.

HTH.

-Bill (http://ucguerrilla.com)

[Matthew Loggan]

Thanks William,

I review the tftp logs, but I see nothing strange, maybe I will consider restarting the call manager cluster.

regards.

I

review

the

tftp

logs,

but I see nothing

strange,

maybe

I will consider

restarting the

call manager

cluster.

regards

.

[antoniosantosneto]

try this from CLI:

enable

conf t

telephony-service

     create cnf-files

restart the IP Phone. If the problem persist put you ephone and ephone-dn configs.

hope help you.

[William Bell]

Antonio,

This is CUCM not CME.

-Bill