Modern Cisco IP Phones use XML files for configuration and maintenance. These XML files are requested by the phone upon startup of the phone (general configuration file) or by pressing buttons for functions like directory, ring tones, background images, etc.

The Trivial File Transfer Protocol is used by most phone models to pull configuration files provided by a TFTP server accessible to the phone. TFTP usually listens on port 69 for requests. If there is no DHCP server providing Option 150 or if the TFTP server is not the same as the DHCP server, the phones have to be configured using an alternate TFTP server in the settings menu, example:

• Settings
• Network Settings
• IPv4 configuration
• Use alternate TFTP Server
• Press * * # to enable access to this setting
• "Yes" Softkey -> Save
• Enter TFTP-Server 1 address below and save again

Upon restart, the phone will then try to pull its configuration file from the TFTP server address you entered before. Details for configuring TFTP services can be found on the page setup tftpboot directory

While TFTP is the commonly used method (and the only one for older phones like 7940/7960) for pulling configuration files, the Java-based Cisco IP Phones (> 7961) also try to download their configuration files via HTTP at first - depending on the phone model and firmware version. The HTTP method can sometimes be faster than TFTP configuration deployment. The web server has to be configured to use port 6970 beside the standard web server port 80 though to enable the phone to pick its configuration via HTTP.

An option to deploy firmware files to many IP Phones at once is the Peer Firmware Sharing. This option is not commonly used and is disabled on the phone by default. It has to be enabled using the 1 config parameter in the SEPXXXXXX.cnf.xml file and works upon restart of the phone. Firmware sharing only works on same phone models running in the same subnet. This method might be used to update 2 or more phones with the same firmware at the same time. The first "master" phone will download the firmware files from the TFTP and the other "slave" phones will download the files from the "master" phone locally. While this function might save some network bandwidth, the "slave" phones are stuck in the firmware download screen till all downloads are finished and firmware updates on a production site might take very long.