7960 Not provisioning onto public network, but does locally

Hello All,

I’m trying to figure out why I can’t get a 7940/7960 Cisco phone to provision properly to an external VoIP server.

I have the configuration for DHCP to provide bootp to the VoIP server and even have additional tftp settings pointing to the same server.
Options: 66,128,150 all point to the TFTP/VoIP server.
I can boot SPA504.x and other SPA phones, but when I configure an 79xx, it appears to never communicate to the server so of course it can’t get the configuration.
I have verbosity on for the TFTP server and it doesn’t appear that it is communicating at all.

Any ideas?

Thanks!

For the Cisco 7940/60 series phones, you really only need option 150, it will fall back to option 66 if option 150 is not available. I’m unsure exactly what you mean by external voip server. If by that you mean that the server is at another location, i.e not on your local LAN, then make sure that your NAT settings are good, assuming that you are using NAT, and that you have connectivity to the other network. If you manually set the IP, Default Gateway and TFTP server addresses on the handset, does the handset at least attempt to reach it’s destination network? Are you forwarding at least ports TCP/UDP 5060 and 16384? What firmware are you using, SIP or SCCP? Can you provision the handsets using your PC and a local DHCP/ TFTP server? If so, post your handset config files without your personal information in case you have something obvious in there that’s causing the issue. I can’t think of anything else off the top of my head right now that might cause the issue. Hope that gives you a pointer or two…

If you are using tftp you willl need UDP/69 open both ways.

Sorry for the delay, and thanks for the reply Dicko,

I believe for testing purposes we have everything wide open so port 69 should work.

Would the 7900 phones require more than the 504G’s?

Thanks for the reply i_know_nuffin,

We are using SIP. We are defining both 66 & 150 and the part that is concerning is that the 504G’s work perfectly compared to the 7900 series.
We do have “everything” open, but will have to verify to be certain port 16384.
On the extension configuration we do have NAT set, similarly to the 504G.
Yes local provisioning works like a charm with those phones, it’s across the wire that gets us.

Thanks!

Some more rambling:

How is it setup? Are your DHCP/ TFTP servers on the local LAN and the PBX on a remote network or are you tunneling to the remote network and picking up the config from there? If so, are the VPN settings letting your DHCP/ TFTP servers through the tunnel? Is there a router of any kind sitting between the handset and the DHCP/ TFTP servers? If so, are you forwarding broadcasts? In your phone config do you have the external (public) IP address of your local network set under nat_address and nat_enable is set to 1? What do you have set as the proxy address in the phone config file?

Going back to my first reply, if you manually enter the config on the handset, does the handset at least attempt to reach the remote network? Even if it doesn’t necessarily register with the PBX. Have you confirmed connectivity to the remote network from the phone port? Have you tried manually setting up the handset and telnetting to it from both the local and remote networks? What does the debug say is going on? Post a copy of your handset config files without your personal info just in case there is something in there causing you a problem.

Sometimes the sip firmware doesn’t quite work properly, or appears buggy. I am using P003-8-12-00 without trouble. If you are certain all else is as it should be, try a firmware change on a handset.

There is a small router which blocks nothing and allows everything to go through, that device is servicing DHCP and provides an IP number as well as all the options to the devices plugged in. The phone system is what it’s pointed to which is a public IP address ( yes extension has NAT programmed ). With the 504G it’s an automatic, it just works, but the 7940/60 in my opinion doesn’t seem to be communicating with the server on the other side. I have turned up the verbosity on tftp in order to see more but in the end I feel like the phone doesn’t communicate with the server.

I will try manual now and update.

Generally I find that these things cause trouble for the simplest of reasons, although Cisco don’t exactly make it easy to play the open standards game either. Take nothing for granted with your setup, it’s usually the easy peasy stuff that gets misconfigured, like a digit wrong on the gateway address handed out from the DHCP server etc. Keep plugging away with it, at some point you’ll have that “smack your forehead” moment :>)

I reconfigured everything to be 100% sure, I was able to plug in an SPA504G, came up, made a phone call everything great.
I plugged in the 7960 nothing.
I manually set the TFTP server address to the external server since it didn’t pick up option 66 or 150. At that point the phone did connect to the server download extension information but then I couldn’t make phone calls.

I looked at sip show peers for the 504 and received:
504/504 10.1.20.102 D A 5060 UNREACHABLE
But works like a charm
The 7960 shows:
7960 (Unspecified) D N A 0 UNKNOWN

When looking in the asterisk logs, nothing shows up on an attempted dial from the 7960.

This is a frustrating one.

You mentioned that everything is wide open port wise, so perhaps remove the NAT settings temporarily, set static addresses and just have a straight connection to test, once you get it working without NAT, you can then re-apply the NAT settings. There is obviously something amiss with the SIP configuration if it is unable to register with the PBX, but able to download the firmware and config files from it. Post a copy of your handset config files without your personal info.

If I manually override the DHCP setting and provide the TFTP address, the phone does in fact connect and get the configuration. This is still a problem since we are providing DNS options 66 & 150, but lets say you have to type it thats part 1.

In checking the SIPxxxxxxxxxxxx.cnf file, I see that the nat_enable: option is set to ZERO even though the extension says NAT YES, so that’s a bug.
Once those 2 parts are set, the phone works like a champ!

Thanks for your help!

Do you have your options set right? You have to send option 66 as a BCD encoded IP address (dotted quad as some call it) not in ASCII. Do not use any suffic or prefix.

Yes, both 66 & 150 are set to x.x.x.x and the phone seems to ignore it and shows some default address of 50.48.57.46 as the TFTP server. We can fully provision these when they are in the local network and they get to the pbx to grab the configuration.
No prefix or suffix.
Cisco documentation recommends 150 which is why we included it.
We ran into this before and simply said we couldn’t use those phones, but this time I broke down to figure out exactly why.

50.48.57.46 is part of Frontier Communications, Perhaps you have a phone “locked” in some way to that vendor?

nmap -v -sU -p 69 50.48.57.46

shows you that. As a workaround, re-route 50.48.57.46 to your tftp server on the router it is behind.

Congrats, progress at last!

Cisco handsets store the last good settings in local flash, if it can’t update or confirm those via DHCP for some reason, it will apply the locally stored copy. I’m guessing that the rogue TFTP server address of 50.x.x.x was the last known good address that the handset received. Resetting the handset to defaults should clear it. However, it does suggest that the TFTP settings are not being propagated by DHCP as you expect, so I would look a little closer at the DHCP server config.

Also when using NAT, the handset config file must have your public IP address of the local network set for the nat_address field and nat_enable must be set to 1. If you happen to have a dynamic IP address assigned by your ISP, this could cause you trouble.

One possible solution might be to use a dynamic DNS service, like No-IP or DYDNS etc. Instead of placing the dotted decimal IP address in the nat_address field of the handset config, you would use the dynamic URL instead. That way you should always have access to the assigned public IP from your ISP whenever the handset boots, assuming of course that your update client is working as it should.

Good luck with it :>)