7911 Phone load and corporate directory

Brian Houston · ‎11-30-2009

Hi

I have UCM 7.0.2 with several 7911 phones registered at the main site, where UCM is located.

I have insalled 17 new 7911s at a remote site which has a 10M LES circuit connected to the corporate WAN - this provides conectivity back to UCM. DHCP service for the new phones is provided by a LAN switch at the remote site. DHCP server has option 150 pointing the phones to the UCM Subscriber at the main site.

The new phones register OK and can make/receive calls. The problems are:

> Phones cannot access the Global Directory. The message "host not found" is displayed. When I browse to the phone URL, I can see that the hostname of UCM 1 is something I don't recognize - certainly not the IP address of the UCM which is what is displayed on the web page of the main site phones. URLs for the directory services also display this hostname instead of the UCM IP address. I know this is why I can't reach the Global Directory but I don't know where the hostname is coming from.

> Phones don't upgrade to the firmware specified in the Device Defaults. Even when I specify the phone load on an individual phone, it just boots with the firmware it is already loaded with.

In the phone logs I can see TFTP timeouts for the phone MAC, eg aaaabbbbcccc.cnf.xml. It seems like a TFTP problem but the phones do register correctly and make/receive calls. so I know they're getting their configuration from UCM.

I'm sure the two problems above are related. I asked the customer if there were any firewalls in the WAN path that could be causing a problem with TFTP but they're adamant that nothing is being blocked. The only difference between the main and remote sites is the presence of the WAN in the case of the remote site.

Any ideas?

Jaime Valencia · ‎11-30-2009

All the URLs for directories, services, help, etc are under service parameters and by default they use hostname, best practice is to have them with IPs

i do agree that most of the times the problem is something in between causing the timeout, if not a FW or ACL maybe something inspecting the packets and delaying them or lack of QoS for TFTP.

You can look at TFTP logs to make sure the can communicate and if CUCM is also detecting a timeout.

If you want to go further a sniffer would really show if there is something blocking the communication or not.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

HTH

java

if this helps, please rate