The HTTP headers that are sent with any page from an HTTP server can include a Refresh setting. This setting comprises two parameters: a time in seconds and a URL. These two parameters direct the recipient to wait the time given in the seconds parameter and then get the data to which the URL points.

The Cisco Unified IP Phone HTTP client properly supports this setting, which gives a great deal of power to service developers. It means that a new page can replace any XML object that displays after a fixed time.

The following figure shows an example of how to use the refresh setting. This sample page shows the user the current value of Cisco stock.

• A splash screen that displays the Yahoo logo.

• After a very short time, the screen displays the numeric Cisco stock parameters.

• Finally, the screen shows a graph of Cisco intraday stock performance. The display repeatedly cycles between the final two views.

Refreshing the display can occur without user intervention, because the display automatically cycles if a timer parameter is specified. On any given screen, however, the user can force an immediate reload by pressing the Update softkey. Also, if a timer parameter of 0 was sent in the header, the page never automatically reloads. In this case, the display will move to the next page only when the Update softkey is pressed. If no refresh URL is specified, the current page gets reloaded.

Although delivering pages with the proper MIME type and other formatting items is not difficult, you require a moderately in-depth knowledge of your web server. The following code excerpt, written in JavaScript and used with Microsoft IIS and ASP, sets these values in a few lines:

<%@ Language=JavaScript %>
<% 
Response.AddHeader( "Refresh", 
                    "3; url=http://services.cisco.com/s/q.asp");
Response.ContentType = "text/xml";
//
// Additional page content here
//
%>

Usually, you can set the MIME type for pages in any web server by simply performing an association to the .xml file extension. Your web server documentation should explain how to accomplish this association. This action allows you to serve static pages without the need for writing script.

If you want to deliver dynamic content by using the other supported HTTP headers, you need to understand how to generate the HTTP headers using the desired programming language and have common gateway interface (CGI) or script access on the target web server.

The expiration header can control which URLs are added to the phone URL history. This behavior differs slightly from traditional web browsers but is implemented to perform the same function. Disable the Back button functionality to avoid calling a URL twice.

This functionality allows you to expire the content of any page that is sent to the phone. When a user presses the Exit softkey, the user goes back to the last URL that did not expire when it was loaded. This action differs from traditional browsers by not considering the current freshness of the data but the freshness of the data when the URL was requested. This functionality requires you to have a page expire when it is first loaded and to not set a time and date in the future.

The following example shows how to have content on IIS expire by using Active Server Page (ASP):

<%@ Language=JavaScript %>
<%
   Response.ContentType = "text/xml";
   Response.Expires = -1;
%>

The "Expires" property specifies the number of minutes to wait for the content to expire. Setting this value to -1 subtracts 1 minute from the request time and returns a date and time that have already passed.

Note	The Cisco IP Phone 8800 Series requires that the expire date be after 1970/1/1.

A cookie is the term for a mechanism that the Web server uses to give the client a piece of data and have the client return the data with each request. The two traditional uses for cookies are:

For Web sites to store a unique identifier or other information on the client's file system. The information is available to the Web server on subsequent visits.

To track a unique identifier for state management. The client returns the cookie with each request and the server uses this identifier to index information about the current session. The identifier is commonly referred to as a session ID. Most Web servers have a built-in session management layer that uses this second type of cookie, which is commonly referred to as a session cookie.

The following example shows the Set-Cookie header that is returned to the browser when a request method is used:

Set-Cookie: ASPSESSIONIDGQGQGRLS=OCPNMLFDBJIPNIOOKFNFMOAL; path=/

The Cisco Unified IP Phone can receive and use a total of four cookies per host per session and can store information for up to eight sessions at once. Each cookie can be up to 255 bytes in size. These cookies are available until the server terminates the session or the client session has been idle for more than 30 minutes. On many phones which are capable of running multiple applications concurrently, the session state is also cleared when the application window closes. This behavior is consistent with PC-based browsers and provides better security because anyone attempting to reopen a secure application would be forced to authenticate. If the client is connecting to a new server and all session resources are in use, the client clears and reuses the session with the longest inactivity time.

When using ASP on IIS, the default server configuration automatically generates a session cookie and sends the cookie to the client using the Set-Cookie header. This cookie enables you to use the Session object from within ASP to store and retrieve data spanning multiple requests for the life of the session. When using JSP on Tomcat, the default configuration generates and issues a session cookie.

The encoding header controls language and character settings related to localization.

This Cisco-proprietary header contains the Cisco manufacturing Model Name of the device, which can typically be found by going to the Settings menu on the phone. The navigation path vary from models. Here are some examples:

• On Cisco IP Phones with Multiplatform Firmware:

  Settings > Status > Product

• On Cisco IP Phones On-Premises:

  Settings > System Information > Phone Information

  On Cisco Video Phone 8875 and Cisco Desk Phone 9800 Series:

  Settings > About this device

Some examples of manufacturing Model Names are CP-7861, CP-8875, CP-8845, and DP-9841.

This Cisco-proprietary header contains the display capabilities of the requesting device with the following parameters (listed in the order in which they appear):

• Width (in pixels)

• Height (in pixels)

• Color depth (in bits)

• A single character indicating whether the display is color ("C") or gray scale ("G")

These parameters get separated by commas as shown in the following example header:

x-CiscoIPPhoneDisplay: 298, 168, 12, C

Note	The pixel resolutions advertised by the device define the area of the display accessible by the phone services; not the actual resolution of the display.

This Cisco-proprietary header contains the version of the IP Phone Services SDK that the requesting phone supports. The HTTP header does not specify which URIs are supported. Therefore, you must check the Supported URIs matrix in the IP Phone Services SDK to determine which URIs are supported based on the Phone Model Name and supported SDK version.

Note	Beginning with the IP Phone Services SDK 3.3(3), the SDK version number matches the minimum Cisco Unified Communications Manager software that is required to support it. For example, SDK version 3.3(4) gets supported only on Cisco Unified Communications Manager version 3.3(4) or later.