SCCP boot up process.

[sarahr202]

Hi everybody

A quick question about SCCP phone boot up process.

This is my understanding when phone boots up:

1. SCCP phone obtains the Power (PoE or AC adapter).

2. The phone loads its locally stored firmware image.

3. The phone learns the Voice VLAN ID via CDP from the switch.

4. The phone uses DHCP to learn its IP address, subnet mask, default gateway and TFTP server address.

5.  The phone contacts the TFTP server and requests its configuration file.  Each phone has a customized configuration file named  SEP<mac_address>.cnf.xml created by CUCM and uploaded to TFTP when  the administrator creates or modifies the phone.

6.  The phone registers with the primary CUCM server listed in its  configuration file. CUCM then sends the softkey template to the phone  using SCCP messages.

Please focus on step 5, among other things, this configuration file also contain the " firmware file " name( or load) that a phone should have. So when SSCP phone receives this config file, it checks its own firmware against the firmware 's file name in the configuration file. If it does not match, phone then request the firmware file mentioned in config file from tftp server and loads it.

After that phone proceeds to step 6( phone registration)

The important thing to note is if there any mismatch between firmware on the phone and the firmware specified in config file. it is resolved at step 5 i.e before phone attempts to register with CUCM.

This is my understanding.

However, I find some conflicting information.

For example consider the following from the link:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_0_1/ccmsys/a02tftp.html

After obtaining the configuration file from the TFTP server, a device  attempts to make a TCP connection to the highest priority Cisco Unified  Communications Manager in the list that is specified in the  configuration file. If the device was manually added to the database,  Cisco Unified Communications Manager identifies the device. If  auto-registration is enabled in Cisco Unified Communications Manager,  phones that were not manually added to the database attempt to  auto-register in the Cisco Unified Communications Manager database.

Cisco Unified Communications Manager informs devices that are using .cnf  format configuration files of their load ID. Devices that are  using .xml format configuration files receive the load ID in the  configuration file. If the device load ID differs from the load ID that  is currently executing on the device, the device requests the load that  is associated with the new load ID from the TFTP server and resets  itself. For more information on device loads,

Above load id refers to firmware. 

According to above paragraph, any mismatch of firmware i.e if the the phone is running different firmware from the one specified in config file, is resolved when the phone attempts to register with CUCM. 

I thought any mismatch between firmware on the phone and the firmware specified in the config file is resolved when phone contacts tftp and requests its configuration file. However the above paragraph suggest that phone does that when it attempts to register with cucm.

I appreciate your help.

thanks and have a great day.

[acampbell · Accepted solution]

Sarah,

Have alook at this link.

This is what cisco teach

http://www.ciscopress.com/articles/article.asp?p=1745631&seqNum=7

Regards,
Alex.
Please rate useful posts.

[rahaggar · Accepted solution]

This   figure provides an overview of the startup process for a Cisco IP  Phone if you  are using a Cisco Catalyst switch that is capable of  providing Cisco  prestandard Power over Ethernet (PoE).

1. Obtain  power from the switch: If  you are using a Cisco switch that is capable of  providing Cisco inline  power, the switch will send a Fast Link Pulse (FLP)  signal. The switch  uses the FLP to determine if the attached device is an  unpowered Cisco  IP Phone. In the unpowered state, a Cisco IP Phone loops back  the FLP,  signaling the switch to send -48 V   DC power down the line.
2. Load  the stored phone image: The  Cisco IP Phone has nonvolatile Flash memory in  which it stores  firmware images and user-defined preferences. At startup, the  phone  runs a bootstrap loader that loads a phone image stored in Flash memory.   Using this image, the phone initializes its software and hardware.
3. Configure  VLAN: After  the IP Phone receives power and boots up, the switch sends a  Cisco  Discovery Protocol packet to the IP Phone. This Cisco Discovery Protocol   packet provides the IP Phone with voice VLAN information, if that  feature has  been configured.
4. Obtain  IP address and TFTP server address: Next,  the IP Phone broadcasts a request  to a DHCP server. The DHCP server  responds to the IP Phone with a minimum of an  IP address, a subnet  mask, and the IP address of the Cisco TFTP
5. Contact  TFTP server for configuration: The  IP Phone then contacts the Cisco TFTP  server. The TFTP server has  configuration files (.cnf file format or .cnf.xml)  for telephony  devices, which define parameters for connecting to Cisco  CallManager.  The TFTP server sends the configuration information for that IP  Phone,  which contains an ordered list of up to three Cisco CallManagers. In   general, any time you make a change in Cisco CallManager that requires a  phone  (device) to be reset, a change has been made to the  configuration file of that  phone. If a phone has an XML-compatible  load, it requests an XMLDefault.cnf.xml  format configuration file;  otherwise, it requests a .cnf file.
   If you  have enabled auto-registration in Cisco  CallManager, the phones access a  default configuration file  (sepdefault.cnf.xml) from the TFTP server. If you  have manually entered  the phones into the Cisco CallManager database, the phone  accesses a  .cnf.xml file that corresponds to its device name. The .cnf.xml file   also contains the information that tells the phone which image load that  it  should be running. If this image load differs from the one that is  currently  loaded on the phone, the phone contacts the TFTP server to  request the new  image file, which is stored as a .bin file.
6. Register  with Cisco CallManager: After  obtaining the file from the TFTP server, the  phone attempts to make a  TCP connection to the highest-priority Cisco  CallManager on the list.

Regards

Rahaul Aggarwal

[Richard McLoughlin]

Very helpful and succinct response Rahaul. 

In a windows server 2012 DHCP environment, are you able to confirm if the phone behaves in a similar manner to other clients in that:-

The first DHCP request will recieve an IP address offer which will have a lease duration of 30 minutes

After 30 minutes the IP phone will issue a DHCP renew request and the next offer will be for the full lease period (in our case 7 days).

With a lease period of 7 days, can I expect the phone to issue another renew request at 3.5 days (50% of lease period) or is this behaviour specific to windows clients?

I'm trouble shooting a scenario where an IP phone is dropping a call mid-conversation and then displaying  UCM down  features disabled.

It appears (from the DHCP logs) to be assigned an address, request a renewal of that address 30 minutes later and then release the address 38 minutes after that. 

Of the 3500 phones we have and with only 5 reports of this behaviour which points to a badly behaved phone. All of this is based on CUCM 11.0, Cisco 7961 running 9-4-2SR1-1S).

Sorry I've hi-jacked this thread with irrelevant content now but I was just trying to explain the reasoning behind my question.

Best

Richard

[sarahr202]

Hijacker:)