All Cisco IP Phones contact the Cisco EDOS RC server until they are provisioned initially.

In an RC distribution model, a customer purchases a Cisco IP Phone that has already been associated with a specific Service Provider in the Cisco EDOS RC Server. The Internet Telephony Service Provider (ITSP) sets up and maintains a provisioning server, and registers their provisioning server information with the Cisco EDOS RC Server.

When the Cisco IP Phone is powered on with an internet connection, the customization state for the unprovisioned Cisco IP Phone is Open. The phone first queries the local DHCP server for provisioning server information and sets the customization state of the Cisco IP Phone. If DHCP query is successful, Customization State is set to Aborted and RC is not attempted due to DHCP providing the needed provisioning server information.

If DHCP server does not provide provisioning server information, the Cisco IP Phone queries the Cisco EDOS RC Server and provides its MAC address and model and the Customization State is set to Pending. The Cisco EDOS server responds with the associated service provider's provisioning server information including provisioning server URL and the Cisco IP Phone's Customization State is set to Custom Pending. The Cisco IP Phone then performs a resync URL command to retrieve the Service Provider's configuration and, if successful, the Customization State is set to Acquired.

If the Cisco EDOS RC Server does not have a service provider associated with the Cisco IP Phone, the customization state of the Cisco IP Phone is set to Unavailable. The phone can be manually configured or an association added for the service provider of the phone to the Cisco EDOS Server.

If a phone is provisioned via either the LCD or Web Configuration Utility, prior to the Customization State becoming Acquired, the Customization State is set to Aborted and the Cisco EDOS Server will not be queried unless the phone is factory reset.

Once the phone has been provisioned, the Cisco EDOS RC Server is not utilized unless the phone is factory reset.

Cisco IP Phones support TFTP for both provisioning resync and firmware upgrade operations. When devices are deployed remotely, HTTPS is recommended, but HTTP and TFTP can also be used. This then requires provisioning file encryption to add security, as it offers greater reliability, given NAT and router protection mechanisms. TFTP is useful for the in-house preprovisioning of a large number of unprovisioned devices.

The Cisco IP Phone is able to obtain a TFTP server IP address directly from the DHCP server through DHCP option 66. If a Profile_Rule is configured with the filepath of that TFTP server, the device downloads its profile from the TFTP server. The download occurs when the device is connected to a LAN and powered up.

The Profile_Rule provided with the factory default configuration is $PN.cfg, where $PN represents the phone model name, such as CP-7832-3PCC. For example, for a CP-7832-3PCC, the filename is CP-7832-3PCC.cfg. For a device with the factory default profile, upon powering up, the device resyncs to this file on the local TFTP server that DHCP option 66 specifies. (The filepath is relative to the TFTP server virtual root directory.)

The Cisco IP Phone behaves like a browser that requests web pages from a remote Internet site. This provides a reliable means of reaching the provisioning server, even when a customer router implements symmetric NAT or other protection mechanisms. HTTP and HTTPS work more reliably than TFTP in remote deployments, especially when the deployed units are connected behind residential firewalls or NAT-enabled routers. HTTP and HTTPs are used interchangeably in the following request type descriptions.

Basic HTTP-based provisioning relies on the HTTP GET method to retrieve configuration profiles. Typically, a configuration file is created for each deployed Cisco IP Phone, and these files are stored within an HTTP server directory. When the server receives the GET request, it simply returns the file that is specified in the GET request header.

Rather than a static profile, the configuration profile can be generated dynamically by querying a customer database and producing the profile on-the-fly.

When the Cisco IP Phone requests a resynch, it can use the HTTP POST method to request the resync configuration data. The device can be configured to convey certain status and identification information to the server within the body of the HTTP POST request. The server uses this information to generate a desired response configuration profile, or to store the status information for later analysis and tracking.

As part of both GET and POST requests, the Cisco IP Phone automatically includes basic identifying information in the User-Agent field of the request header. This information conveys the manufacturer, product name, current firmware version, and product serial number of the device.

User-Agent: Cisco-CP-7832-3PCC/11.0.1 (00562b043615)

When the Cisco IP Phone is configured to resync to a configuration profile by using HTTP, it is recommended that HTTPS be used or the profile be encrypted to protect confidential information. The Cisco IP Phone supports 256-bit AES in CBC mode to decrypt profiles. Encrypted profiles that the Cisco IP Phone downloads by using HTTP avoid the danger of exposing confidential information that is contained in the configuration profile. This resync mode produces a lower computational load on the provisioning server when compared to using HTTPS.

Note	The Cisco IP Conference Phone 7832 Multiplatform Phones support HTTP Version 1.0, HTTP Version 1.1, and Chunk Encoding when HTTP Version 1.1 is the negotiated transport protocol.

The Cisco IP Phone supports HTTPS for provisioning for increased security in managing remotely deployed units. Each Cisco IP Phone carries a unique SLL Client Certificate (and associated private key), in addition to a Sipura CA server root certificate. The latter allows the Cisco IP Phone to recognize authorized provisioning servers, and reject non-authorized servers. On the other hand, the client certificate allows the provisioning server to identify the individual device that issues the request.

For a service provider to manage deployment by using HTTPS, a server certificate must be generated for each provisioning server to which a Cisco IP Phone resyncs by using HTTPS. The server certificate must be signed by the Cisco Server CA Root Key, whose certificate is carried by all deployed units. To obtain a signed server certificate, the service provider must forward a certificate signing request to Cisco, which signs and returns the server certificate for installation on the provisioning server.

The provisioning server certificate must contain the Common Name (CN) field, and the FQDN of the host running the server in the subject. It might optionally contain information following the host FQDN, separated by a slash (/) character. The following examples are of CN entries that are accepted as valid by the Cisco IP Phone:

CN=sprov.callme.com
CN=pv.telco.net/mailto:admin@telco.net
CN=prof.voice.com/info@voice.com

In addition to verifying the server certificate, the Cisco IP Phone tests the server IP address against a DNS lookup of the server name that is specified in the server certificate.