Overview & Cisco IP Phone XML Objects

  • This article was written from book in the following url: Cisco Unified IP Phone Services Application Development Notes Release 6.0
  • Users access these features using the services and directories buttons or menu
  • When a menu selection is made, the Cisco Unified IP Phone acts on it by using its HTTP client to load a specific URL. The return type from this URL can be plain text or one of the CiscoIPPhone XML objects. The object loads and the user interacts with the object
  • HTML Disclaimer: Phone service developers must take into consideration that the phone is not a web browser and cannot parse HTML. Although content is delivered to the phone through HTTP messages by using a web server, keep in mind that the content is not HTML. All content comes either as plain text or packaged in proprietary XML wrappers
  • Appropriate behavior of IP Phone depends solely on the type of data that has been delivered in the page
  • The following sections provide definitions and descriptions of each CiscoIPPhone XML object:
    • CiscoIPPhoneMenu (See XML Definition page 20):
      • A menu on the phone comprises a list of text items, one per line
      • Cisco Unified IP Phones allow a maximum of 100 MenuItems. Each MenuItem includes a Name and an associated URL
      • After the user chooses a menu option, the phone generates an HTTP request for the page with the URL or executes the uniform resource identifiers (URIs) that are associated with the menu item
    • CiscoIPPhoneText (See XML Definition page 21)::
      • Displays ordinary 8-bit ASCII text on the phone display. The <Text> message must not contain any control characters, except for carriage returns, line feeds, and tabs
      • Note: Cisco Unified IP Phones support the full ISO 8859-1 (Latin 1) and Shift_JIS character sets
      • Non-XML Text: Here we  only describes the supported CiscoIPPhone XML objects. You can also deliver plain text via HTTP. Pages that are delivered as MIME type text/html behave exactly the same as XML pages of type CiscoIPPhoneText. One important difference is that you cannot include a title or prompt
    • CiscoIPPhoneInput (See XML Definition page 22)::
      • When a Cisco Unified IP Phone receives an XML object of type CiscoIPPhoneInput, it constructs an input form and displays it. The user then enters data into each input item and sends the parameters to the target URL
      • The InputItem tag delimits each item in the list. The number of InputItems must not exceed five
      • Table of InputFlags Attribute:

image

  • CiscoIPPhoneDirectory (See XML Definition page 24)::
    • See this sample:

image

  • CiscoIPPhoneImage(See XML Definition page 25):
    • The CiscoIPPhoneImage provides a bitmap display with a 133 x 65 pixel pane that is available to access services. Each pixel includes four grayscale settings. A value of three (3) displays as black, and a value of zero (0) displays as white
    • Setting the X and Y location values to (-1, -1) centers the graphic in the services pane of the phone display
    • Unified IP Phones support a maximum value of 2. A bit depth of 1 is black and white
    • If the number of pixels to be displayed does not represent an even multiple of four, pad the end of the pixel data with blank (zero value) pixels, so the data is packed correctly. The phone ignores the padded data
  • CiscoIPPhoneImageFile (See XML Definition page 30):
    • The Cisco Unified IP Phone 7970, for example, has a display area of 298×168 pixels available to the Services pane and renders images in 12-bit color
    • The CiscoIPPhoneImageFile object behaves like the CiscoIPPhoneImage object, except for the image data. Instead of using the <Data> tag to embed the image data, the <URL> tag points to the PNG image file.
  • CiscoIPPhoneGraphicMenu (See XML Definition page 30):
    • Graphic menus serve the same purpose as text menus: they allow a user to select a URL from a list. Use graphic menus in situations when the items may not be easy to display in a text list
  • CiscoIPPhoneGraphicFileMenu (See XML Definition page 32):
    • CiscoIPPhoneGraphicFileMenu = CiscoIPPhoneGraphicMenu + Touch Area

image

  • Z-Order Images for better feeling (page 32)
  • CiscoIPPhoneIconMenu (See XML Definition page 33):
    • Text menu + a black/white visual image
  • CiscoIPPhoneIconFileMenu (See XML Definition page 34):
    • Text menu + a colored visual image
  • CiscoIPPhoneStatus (See XML Definition page 36):
  • untitled

    • How to automatically adjust object to screen size (page 37)
    • CiscoIPPhoneStatusFile (See XML Definition page 39):
    • CiscoIPPhoneExecute (See XML Definition page 39):
      • Used to execute requests to phone
      • Limit the requests to three ExecuteItems: only one can be a URL and two URIs per CiscoIPPhoneExecute object, or you can send three URIs with no URL.

    untitled

    • CiscoIPPhoneResponse (See XML Definition page 41):
      • The CiscoIPPhoneResponse object items provide messages and information resulting from CiscoIPPhoneExecute
      • The Status attribute specifies a status code. Zero indicates that no error occurred during processing of the ExecuteItem. If an error occurred, the phone returns a CiscoIPPhoneError object
    • CiscoIPPhoneError (See XML Definition page 41):
      • See errors codes page 4
  • Cisco Unified IP Phones can use custom softkeys with any of the displayable CiscoIPPhone XML objects, excluding the CiscoIPPhoneStatus object which cannot control softkeys and the CiscoIPPhoneExecute object which is not displayable.
  • See Softkey XML Definition page 42
  • If any custom softkeys are defined in the XML object, then all default softkeys are removed from that object. To retain default softkey behavior, then you must explicitly define it in the XML object using a <SoftKeyItem> tag. The internal Softkey URIs can be used in the <URL> tag of <SoftKeyItem> to invoke default softkey actions from custom softkeys
  • The XML parser in Cisco Unified IP Phones does not function as a fully capable XML parser. Do not include any tags other than those defined in your XML display definitions.
  • Since the phone firmware can support multiple encodings, the XML encoding should always be set in the XML header.
    If the XML encoding header is not specified, the phone will default to the encoding specified by the current user locale
  • The encoding value specified in the XML header must match one of the encodings provided by the IP Phone in its Accept-Charset HTTP request header
  • Advertisements

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    w

    Connecting to %s