{"id":182,"date":"2014-03-26T22:05:39","date_gmt":"2014-03-26T22:05:39","guid":{"rendered":"https:\/\/learncisco.net\/index.php\/cucm-ip-phone-registration\/"},"modified":"2023-01-18T02:26:19","modified_gmt":"2023-01-17T19:26:19","slug":"cucm-ip-phone-registration","status":"publish","type":"page","link":"https:\/\/www.learncisco.net\/courses\/icomm-ccna-voice\/endpoint-and-user-administration\/cucm-ip-phone-registration.html","title":{"rendered":"CUCM IP Phone Registration"},"content":{"rendered":"

Network Components<\/h2>\n

When IP phones register with the Communications Manager, they need a little extra. They need an NTP Reference Clock. You can do this several ways. I think the slickest way is to set up one of your routers as a master Network Time Protocol clock. You also have DHCP needs. Phones need IP addresses and with that DHCP offer, they also get the very important TFTP information, option 150 \u2013 that tells them where their TFTP server is, so they can get their configuration files. TFTP server is very, very important, if the phones can’t find that it’s over, we aren’t registering with the Communications Manager because it’s in that file that we find out who we can register with. And then finally, if you’re doing any type of hostname resolution, so host to IP address, then you might need a DNS server. It isn’t necessary if you strictly code IP addresses to your servers. And actually we highly recommend it. It’s not that I don’t love DNS, it’s just that sometimes that extra step may fail. And so now you have to troubleshoot \u2013 well is the DNS server up so that we can find the Communications Manager and find the TFTP server? That’s why I like to hard-code the IP addresses of your servers. Because think about it, typically in a network you’re not re-IPing your servers. You’re giving them their IP addresses and usually you set it and forget it. So why not use just the IP addresses instead of adding that DNS server reliance on all of your devices.<\/p>\n\n\n\n\n\n\n\n
Network Component<\/th>\nFeatures<\/th>\n<\/tr>\n
NTP Reference Clock<\/td>\nA reference clock for device time synchronization. Usually from an external source.
\nAlternatively, a Cisco router can be configured as a mater NTP server.
\nThe Cisco Unified Communications Manager publisher is the NTP client.<\/td>\n<\/tr>\n
DHCP<\/td>\nThe DHCP server provides IP address configuration and TFTP server location to the IP phones.<\/td>\n<\/tr>\n
TFTP Server<\/td>\nThe TFTP server provides device configuration files, ringer files, and firmware upgrades to the IP phones. Cisco Unified Communications Manager can provide both – DHCP and TFTP services.<\/td>\n<\/tr>\n
DNS Server<\/td>\nProvides hostname to IP address resolution to the IP phones and user PCs.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Network Time Protocol<\/h2>\n

The Network Time Protocol, which is highly recommended, lets all of your network devices keep the same time. Why is that important? Well, think about looking up call detail records. It could be spanning across many servers and devices, and so if you have a specific time that you are looking for and that matches in all those files it’s so much easier to do your troubleshooting. You might want to have a publisher that’s going to synchronize the master NTP clock source, and that can be a router. You can make the router your mater NTP server. And you can also use an external clock that everybody synchronizes with. But why not make it within your network. Again kind of removing that external step in case the external server’s not available, your internal server can certainly work for you to keep everybody in sync. Now subscribers, they get their clock from the publisher, that’s why the publisher needs to synchronize with that master NTP clock source. And then the IP phones get their information to display the time\u2013out on the display from the Communications Manager that they register with. So you can see how everybody ties together, the phones get it from their subscribers they registered with, the subscriber gets it from the publisher and then the publisher gets it from whatever source you want to set as the master clock.<\/p>\n

There is a hierarchy that you can set up for NTP. NTP uses a term called stratum. And the lower the stratum number, the closest to that clock source. So what’ll happen is a stratum 1 time server, that has radio or atomic clock directly attached to it; a stratum 2 gets it from the stratum 1 time server; and then the stratum 3 gets it from the stratum 2 server; and so on down the line. The lowest stratum number, is preferred by your clients if we had multiple sources. So stratum 1 that’s the best. An external NTP reference clock is preferred by the publisher and an internal NTP reference is actually the backup. So you can set this up to make sure that you have an external NTP server that ensures accurate system time on the first node of your publisher or the first node. This ensures that the external NTP server is a stratum 9 or higher. Highest internal NTP server is going to be a stratum of 1. Why do we want to do it this way? Well we want to make sure that all of our internal devices believe the device that we set up to have distribute the time. Because even if you do get it from that external source or not, we want to make sure that they don’t look at that external source. We want them to look internally, so we have control over the time synchronization of everything. Now this isn’t just for your IP phones, all of your routers should be in sync, all of your switches, your voicemail system \u2013 all should be tied to that internal NTP server with the stratum of 1, so that everything is seeing the same time. Nothing worse and than all of your devices all being off.<\/p>\n

Special Functions Used by Cisco IP Phones<\/h2>\n

The IP phones need power, so in order to provide power to our phones we have several options. We can purchase separately the little brick that we plug into the wall and plug into the phone, so each phone has individual power. I don’t really like that offer, I like Power over Ethernet (PoE). Now we don’t require the wall power, we can obtain power through the Ethernet connection back to our switches. So our switches have to be able to provide the power. Why do I like this better? Well, first of all the clutter. Second of all, in a backup situation, what if the building lost power. I’m thinking that not every user has a battery backup system plugged into the wall that all their stuff is plugged in to. But my guess is your closet, where your routers and your switches live, might have battery backup, so in the event of a power failure you still have phone capabilities. For security I think that’s very important, so you might want to consider looking at getting Power over Ethernet out to our phones.<\/p>\n

Okay, once they get power, there are another requirements of this puzzle.<\/p>\n