Endpoints and Endpoint Management
Registration lifecycle
A Cisco IP Phone powers up via PoE, gets an address by DHCP (option 150 supplies TFTP server addresses), downloads its configuration file from TFTP, then registers - SCCP on TCP 2000, SIP on UDP/TCP 5060 - and holds that connection as a keepalive. A phone stuck at Configuring IP never got DHCP; a phone at Registering reached TFTP but was rejected or unknown to CUCM. Check the device pool, DN association, and whether the MAC is configured or falls inside an auto-registration range.
Configuration hierarchy
Enterprise parameters, then service parameters, then device defaults and common phone profile, then device pool, then the individual device. The device pool carries region, location, date/time group, SRST reference, and locales; button and softkey templates control the physical and softkey UI.
Trust and security
Phones trust CUCM through the ITL (built by CAPF and TVS) and, in mixed mode, the CTL. A Locally Significant Certificate is issued by CAPF; an MIC is burned in at manufacture. ITL/CTL mismatch is the usual cause of security errors after a cluster rebuild.
Provisioning at scale
BAT imports phones, users, and lines from CSV; self-provisioning lets a user claim a DN through an IVR; Extension Mobility logs a user into any phone using a device profile; Device Mobility adjusts region and location when a phone moves between sites.
Rule of thumb: registration failures are nearly always DHCP/option 150, TFTP reachability, or a trust-list problem, in that order.
Traps: assuming a phone needs DNS to register (it does not if option 150 and TFTP work); putting button templates in the device pool instead of the common phone profile or device defaults.