Need to send hostname to phone, not IP address

Answered Question
Apr 7th, 2009

Spent 2 weeks with various configs with some limited success on our new UC520 ...

I need to configure the system to send out the hostname of the UC520 rather than the IP address to the phones (so that the phones will look up the IP of the callmanager). As far as I can tell this info gets pushed out via the tftp load to the phone.

[If anyone is wondering why, its because there are some NAT rules doing some translations for phones in a couple of locations... maybe not the best way, but that is how its been on the old CM4 box]

I have had this working, but somehow didn't keep the config (probably changing too many things at once). I have also had this working on CM4 a while ago.

Any help greatly appreciated.

I have this problem too.
0 votes
Correct Answer by Steven Smith about 7 years 8 months ago

processNodeName is the name of the field for it.  I could not explain to you why it would so something else.  Did you turn on per phone CNF-files?  I would go under telephony-service and do a no create cnf-files, create cnf-files.  After that, I would to a restart all from the command prompt to make sure that all the phones get restarted.  It could be that the phones came back up after the reboot of the UC520, and the tftp process was too busy.  I am guessing at this point.  But, I would try restarting individual phones for now and see what happens.

Correct Answer by Marcos Hernandez about 7 years 8 months ago

What if you did this:

1) Create a loopback interface and assign the external IP to it (20.20.20.20) in this example:

UC500#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
UC500(config)#int lo100
UC500(config-if)#ip address 20.20.20.20 255.255.255.0
UC500(config-if)#no shutdown


2) Configure this as the CME Main IP:

UC500(config-if)#telephony-service
UC500(config-telephony)#ip source-address 20.20.20.20

3) Update the configuration files:

UC500(config-telephony)#create cnf-files

This will only work if the default gateway for the IP phones on your LAN is the UC500 itself.

This will cause the configuration to have this IP in the appropriate place, and it is the one that your remote phones will learn:

UC500#more system:/its/XMLDefault7975.cnf.xml           

{7975 Apr 08 2009 09:16:11}


M/D/YA
Central Standard/Daylight Time






2000

20.20.20.20

.

.

.

Let me know if this does the trick.

Marcos

Correct Answer by Marcos Hernandez about 7 years 8 months ago

Now I got you 100%. You are actually talking about the IP in the configurtion sent to the phones, not the load (as in "firmware"). As Steven said, CME can only do IP (and one at at time). However, let me think about this before giving up.

Marcos

Correct Answer by Marcos Hernandez about 7 years 8 months ago

There is still some things I don't understand about your topology. Is the UC500 given a static IP on its WAN interface? Is that what you mean? Is the DHCP server on the same LAN as the UC500? If so, are you using "ip helper-address" to propagate the DHCP offer to the remote phones? Is the PIX doing NAT? What do you mean by "wrong side of the connection"? Is there a VPN tunnel between the UC and the PIX or just regular IP connectivity?

Assuming your UC500 talks to the PIX via the WAN, why don't you just configure the TFTP on your DHCP to match this WAN IP and open the ACL on the UC500 to allow TFTP requests?

Thanks,

Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

Correct Answer by Steven Smith about 7 years 8 months ago

I am making sure I understand what you are looking for.

Using TFTP, you can send option 66 instead of option 150.  Option 66 can be a DNS name.

As far as what the phone receives from tftp, I think that can only be an IP in a CME environment.  In a CM environment, you can absolutely do this by name.  In fact, many tac cases were opened because DNS would stop working and the customers had to change to names instead.  Easy change to make as well in CM.

Another option, which is REALLY UGLY is to create cnf files per phone, then edit the files with the to make this change.  This isn't supported and could cause lots of problems when you make changes.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Correct Answer
Steven Smith Tue, 04/07/2009 - 13:16

I am making sure I understand what you are looking for.

Using TFTP, you can send option 66 instead of option 150.  Option 66 can be a DNS name.

As far as what the phone receives from tftp, I think that can only be an IP in a CME environment.  In a CM environment, you can absolutely do this by name.  In fact, many tac cases were opened because DNS would stop working and the customers had to change to names instead.  Easy change to make as well in CM.

Another option, which is REALLY UGLY is to create cnf files per phone, then edit the files with the to make this change.  This isn't supported and could cause lots of problems when you make changes.

dataIP Tue, 04/07/2009 - 13:51

Hi Steven,

Thanks for the reply....

Re-reading my post, I realise it was not 100% clear.

I am using the network DHCP server (no DHCP configured on the UC520) to push out DHCP info to PCs and phones. This is configured to send out the tftp address (of the UC520) as an IP. All PCs and phones work correctly on this network. The UC520 is given a static address on this network.

I have two phones on the 'wrong side' of a PIX.... this does some NAT.

The two 'external' phones are configured with an alternate tftp setting. This is the address that is NAT'd at the PIX. So,

the phone requests info via tftp, the PIX sees it, NATs it to the correct address, the request arriving at the UC520 correctly. It appears that the info sent out by the UC520 tftp server contains the IP of the UC520 (192.168.0.132 in this case).... so, for the two 'external' phones this is the wrong address (needs to be the one that is NAT'd).

If pushed by name, then the name is resolved to the correct address by the local network, the 'external' network being served by different DNS which will provide the correct NAT'd address.

Now this may sound complex, but is easy in theory.

The part that is confusing is that I ***have*** had both 'external' phones come up, only by altering the config of the UC520.

Also, if I go back to my test CM4 box, then everything comes up okay.

So, in summary, for a given phone, I need to be able to send it an address (either by name or IP) individually.

I guess this is your second option.. its just not clear to me when these files get overwritten by the system... I may be making changes all the time to these files!

In case it is relevant, I am using the latest early adopter software.... don't ask me to go back to the earlier one.... I have a separate problem that CCA 1.9.1 now refuses to 'upgrade' or backup the image... will deal with that one I am back up and running.

Correct Answer
Marcos Hernandez Tue, 04/07/2009 - 18:02

There is still some things I don't understand about your topology. Is the UC500 given a static IP on its WAN interface? Is that what you mean? Is the DHCP server on the same LAN as the UC500? If so, are you using "ip helper-address" to propagate the DHCP offer to the remote phones? Is the PIX doing NAT? What do you mean by "wrong side of the connection"? Is there a VPN tunnel between the UC and the PIX or just regular IP connectivity?

Assuming your UC500 talks to the PIX via the WAN, why don't you just configure the TFTP on your DHCP to match this WAN IP and open the ACL on the UC500 to allow TFTP requests?

Thanks,

Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

dataIP Wed, 04/08/2009 - 00:08

Hi, a bit of further clarification...

The UC520 is connected to the Company LAN via its 'Expansion' interface. The WAN interface is not used. It is given a static IP on this interface.

The ip helper address is given as the existing Company DNS/DHCP server.

The PIX is isolating the pure internal network from a publicly accessible segment. Two phones are on this public segment. The PIX does NAT between these two elements. No VPN, just straight forward IP connectivity.

The Company DCHP server already sends the IP of the UC520 to all the clients on the internal LAN (no problem here)... they can pick this up and then fetch their load info via TFTP (from the UC520).

The external phones have the alternate tftp server address configured... they also can fetch their info from the TFTP server on the UC520 (public address NAT'd by PIX to LAN address of UC520)...

Problem appears to be that the load info sent by the UC520 contains the LAN IP of the UC520.... So external phones don't work.

With the CM4 solution, the phone load showed the CM4 server by name, a local lookup by DNS I assume returned the correct external IP to the phones so they were happy.

It is frustrating as I know I have had both of the external phones up and running on the UC520... Its just that I did not save the config at that point.

Thanks for the help so far.

Correct Answer
Marcos Hernandez Wed, 04/08/2009 - 07:15

Now I got you 100%. You are actually talking about the IP in the configurtion sent to the phones, not the load (as in "firmware"). As Steven said, CME can only do IP (and one at at time). However, let me think about this before giving up.

Marcos

Correct Answer
Marcos Hernandez Wed, 04/08/2009 - 07:27

What if you did this:

1) Create a loopback interface and assign the external IP to it (20.20.20.20) in this example:

UC500#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
UC500(config)#int lo100
UC500(config-if)#ip address 20.20.20.20 255.255.255.0
UC500(config-if)#no shutdown


2) Configure this as the CME Main IP:

UC500(config-if)#telephony-service
UC500(config-telephony)#ip source-address 20.20.20.20

3) Update the configuration files:

UC500(config-telephony)#create cnf-files

This will only work if the default gateway for the IP phones on your LAN is the UC500 itself.

This will cause the configuration to have this IP in the appropriate place, and it is the one that your remote phones will learn:

UC500#more system:/its/XMLDefault7975.cnf.xml           

{7975 Apr 08 2009 09:16:11}


M/D/YA
Central Standard/Daylight Time






2000

20.20.20.20

.

.

.

Let me know if this does the trick.

Marcos

dataIP Wed, 04/08/2009 - 10:18

I will try this suggestion later today...

It looks like it may give me what I am trying to achieve.

Looking back at my notes, it is possible that I had modified the .cnf.xml file for the phone in question when I said "I have had this working".

Of course, the UC520 will overwrite this file after certain changes occur... Its a work around but not ideal. Your suggestion should get the box to generate the cnf files correctly in the first place.

Back to you after a bit more testing.

Thanks.

Marcos Hernandez Wed, 04/08/2009 - 10:20

If for some reason, the UC500 does not respond to the SCCP registration request on its voice vlan (because you changed the source IP to be the loopback), I have a plan B. But first, let me know if this works.

Marcos

dataIP Tue, 04/14/2009 - 02:34

Hi Marcos,

I tried your suggestion but it did not seem to generate the files required.

I guess this is beacuse I am not using the UC520 as the internet gateway on our network... I have a PIX which is the gateway, this connects to the internet via a 877. On the inside its an HP switch, to which the UC520 and the remainder of the network is connected.

I re-tried editing the cnf files manually, but this time this did not work. Its a bit of a nightmare, as one false move and you get the Blue-Screen-Of-Death on my workstation.... I read there is an issue with Windows boxes reading the filesystem on the Cisco flash... so I guess it is that.... Something bad happend whenever I read the /its directory.

I would like to know if plan B might help me.

Its a bit frustrating as I did have this config running on CallManager4... I thought this step would be easy on the newer box.

dataIP Tue, 04/14/2009 - 07:42

Most odd. I rechecked and am now more confused. I believed the files had not been generated as they did not have the effect I expected... on further checking we find...

Your suggestion does indeed make the .cnf files generate with the correct information.

However, with both internal and external phones the config they receive has the 'old' address in it. This is even after a reboot of the UC520.

Its like the TFTP server isn't sending the cnf files that I think it is.

A couple of issues in the generated cnf files (e.g. need to get the box to change the Timezone and User Locale to UK) but I guess we can sort that later.

The following looks right to me.... but the remote phones pick up 192.168.0.132 (which is an internal address for the UC520)

mercury#more flash:/its/SEP000532FF71C6.cnf.xml



{7960 Apr 14 2009 10:38:55}






2000

195.xxx.xx.179






2

P00308000500

English_United_States
en

United_Kingdom

United_Kingdom

0
http://mercury.xxxxx.uk/voiceview/authentication/authenticate.do
http://195.xxx.xx.179:80/localdirectory




http://195.xxx.xx.179:80/CMEserverForPhone/serviceurl
0
96

1

0


3804



1

mercury#
mercury#

Correct Answer
Steven Smith Tue, 04/14/2009 - 07:50

processNodeName is the name of the field for it.  I could not explain to you why it would so something else.  Did you turn on per phone CNF-files?  I would go under telephony-service and do a no create cnf-files, create cnf-files.  After that, I would to a restart all from the command prompt to make sure that all the phones get restarted.  It could be that the phones came back up after the reboot of the UC520, and the tftp process was too busy.  I am guessing at this point.  But, I would try restarting individual phones for now and see what happens.

dataIP Tue, 04/14/2009 - 12:46

Again very odd behaviour here.

I have got per phone cnf set.

I also do see the relevant entries when I do a more on the relevant cnf file.

Its just when the phone gets its config its not as I expect.

HOWEVER, latest test including no create cnf-files followed by a create cnf-files looks promising.

One of my external phones is now up (the other I can't get to until tomorrow)... more after tests tomorrow morning.

Thanks for the help so far.

dataIP Wed, 04/15/2009 - 02:53

SUCCESS!

Thanks guys for your input on this one.

Looks like the no cnf-file followed by cnf-files may have done the trick. I can't see why, as I did check the generated cnf with the more command before hand.

It would be nice if either a hostname or a set of IPs could be configured for the call processing node. The phones do have entries for additional CM servers... it would be good if the alternative IP could be pushed in to one of those.

My lesson here is to keep better notes and to change only one thing at once... I did have a working solution in earlier tests but couldn't reproduce it (mine used manually edited cnf - which was bad).

Thanks again for everyone's input.

Marcos Hernandez Wed, 04/15/2009 - 06:05

Great. I am happy to hear it worked. Using hostname for Call Control (CME) is actually a very important feature request. I will raise this to the Product Manager for his consideration.

Thanks,

Marcos

Marcos Hernandez Tue, 04/14/2009 - 07:54

Where exactly are you checking? Remember that this modifies not the TFTP server IP (which is given by DHCP) but the call control IP. Check under "settings>device configuration>callmanager configuration" from the phone itself.

Marcos

dataIP Tue, 04/14/2009 - 12:32

Hi Marcos,

Yes, its the call control IP I am looking at.... I see it in the cnf file as the correct IP, but when I look in the phone its got a different IP (that of the UC520 LAN address).

On the remote phone, we see that the tftp server address is correct... (actually manually set as alternate tftp address).. we see it fetch a config by tftp, but when it all settles the CM ip is wrong.

Marcos Hernandez Tue, 04/14/2009 - 06:29

I do not see the latest post you added to the thread. If you are having problems accessing the file system, that is something that you need to address and fix as well. Please open a TAC case so we can help you with that issue.

Creating a loopback and modifying the "ip source" command HAS TO change the CNF defaults. That solution is still best over the other one I had thought about, which involves NAT on the UC500 and which I would have to test.

Let me know,

Marcos

Actions

This Discussion