Http Provisioning; Http Status Code Handling On Resync And Upgrade - Cisco 6800 Series Provisioning Manual

In-House Preprovisioning and Provisioning Servers
VoIP can coexist with NAT only when some form of NAT traversal is provided. Configure Simple Traversal
of UDP through NAT (STUN). This option requires that the user have:
• A dynamic external (public) IP address from your service
• A computer that is running STUN server software
• An edge device with an asymmetric NAT mechanism

HTTP Provisioning

The 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 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 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 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.
The following example is the User-Agent request field from a CP-6841-3PCC:
User-Agent: Cisco-CP-6841-3PCC/11.0 (00562b043615)
When the 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 phone supports 256-bit
AES in CBC mode to decrypt profiles. Encrypted profiles that the 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 phones support HTTP Version 1.0, HTTP Version 1.1, and Chunk Encoding when HTTP Version
1.1 is the negotiated transport protocol.

HTTP Status Code Handling on Resync and Upgrade

The phone supports HTTP response for remote provisioning (Resync). Current phone behavior is categorized
in three ways:
Cisco IP Phone 6800 Series Multiplatform Phones Provisioning Guide
HTTP Provisioning
39