Load=SSCP42.9-03S TFTP Error

[aeriksson]

Hi!

We are intermittently having issue at one of our customers, where phones intermittently restarts and we see in the RTMT the following error message;

The site is a remote site having a H323 GW, 2851 chassi. IOS version below.

Load=SCCP42.9-03S TFTP Error.

They do not get in to Fallback mode, they just restarts. Not all on the site, just a few at a time.

CUCM version is 7.1.3

H323 GW with IOS 124-24

Phone types 7962 and 7942's

We are running skinny betweeen CUCM and the phones.

Have attached a screenshot from the RTMT.

Can not find any info on this, any hints from all of you???

Thanks

Anna

[Joseph Martini]

Do you always see the TFTP error at the same time when the phone restarts?  I wouldn't think that would be related since the phone once it's registered won't need anything from the TFTP service to stay registered, the only time that message should appear is if the phone resets and is trying to download a firmware load 9-0-3S that isn't available on the TFTP server.  The unregistration reason would be indicated in the call manager traces or in the event viewer - application log.  In the application log look for deviceunregister or the device name of the phone that unregistered and you might be able to get a reason code, which can be decoded with this page: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/err_msgs/6_x/alarm611.htm.

[Nathan Compton]

You mention fallback.  Are you having a problem with SRST or are the phones not registering at all?

[aeriksson]

Hi, everything works fine most of the time, it is just intermittently and I can not see that they go unregistered in

the Application Log in the CUCM. If I look in the respectove phones "Debug Display" I see

the following:

For example:

Name= SEP0025xxxxxxx Load=SCCP42.9-0-3S Last=TCP-timeout

Name= SEP0025xxxxxxx Load=SCCP42.9-0-3S Last=TFTP-Error

Name= SEP0025xxxxxxx Load=SCCP42.9-0-3S Last=Initialised.

So whatever it is, it goes so fast so that the CUCM does not unregister the device, but it is irritating for the users as they get their calls cut.

MPLS has been checked and we loose no packets in the EF and AF31 queues. Bandwidth is anyway huge, so can not be the issue.

Greatful for any hints.

[Nathan Compton]

Probably not what you want to hear, but with the TCP timeout happening, that is pointing to some loss of connectivity.  How many phones are at the remote site?  What is the bandwidth of the MPLS link?  TFTP inherently isn't marked with a QOS value, so it's possible that is not being prioritized.  You would have to manually define tftp in your class map over the WAN for QOS.  That is one thing to look at.

By chance, are you using VPN over the MPLS?

Adam Compton