Table Of Contents
Cisco IP Phone Services Application Development Notes
CiscoIPPhone XML Object Quick Reference
XML Objects Used With Nonstreaming URIs
URIs for Pressing Buttons on the Phone
URIs for Invoking SoftKey Functionality
Cisco IP Services Software Development Kit (SDK)
MIME Type and Other HTTP Headers
Content Expiration Header Setting
IP Phone Service Administration and Subscription
Defining IP Phone Service Parameters in Cisco CallManager Administration
Obtaining Technical Assistance
Cisco IP Phone Services Application Development Notes
Use this document with Cisco CallManager 3.3(2) to develop and deploy customized client services for the Cisco IP Phone 7960 and 7940 models, which support Cisco IP Phone services.
Note
Developers using this guide should join the Cisco Developer Support Program because standard Cisco TAC support is limited to the Cisco AVVID installation, configuration, and Cisco-developed applications. This program provides a consistent level of dependable support while leveraging Cisco interfaces in your development projects. For more information about the program and how to join, contact us at developer-support@cisco.com.
Contents
This document covers the following topics:
•
•
•
•
Introduction
You can use Cisco IP Phones, such as the Cisco IP Phone 7960 and 7940, to deploy customized client services with which users can interact via the keypad and display. Services deploy using the HTTP protocol from standard web servers, such as Microsoft IIS. This document provides the information needed for eXtensible Markup Language (XML) and X/Open System Interface (XSI) programmers and system administrators to develop and deploy new services.
Note
Cisco IP Phones have buttons labeled services and directories. When a user presses the services button, a menu of services that are configured for the phone displays. The user then chooses a service from the listing, and the phone display updates.
The following list gives typical services that might be supplied to a phone:
•
•
•
•
•
•
Figure 1 shows a sample text menu created during development.
Figure 1 Cisco IP Phone Text Menu Sample
Cisco IP Phones can also display graphic menus, as shown in Figure 2.
Figure 2 Graphic Menu on a Cisco IP Phone Sample
The way that a service is configured determines whether a graphic or text menu displays.
A phone user can navigate a text menu using the up/down rocker switch followed by the Select soft key, or by using the DTMF keypad to enter a selection directly. Graphic menus do not currently support any type of cursor-based navigation; users simply enter a numeric item selection using the DTMF keypad.
When a menu selection is made, the Cisco 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 then interacts with the user in an appropriate manner for the object.
Figure 3 and Figure 4 show typical displays that result from selecting a service. Figure 3 shows a stock quote that was generated using plain text.
Figure 3 Plan Text Display Example
Figure 4 displays a graphic image.
Figure 4 Graphic Image Display Example
Cisco CallManager limits Cisco IP Phone service activity to a specific Services pane in the Cisco IP Phone display. A service cannot modify the top line of the phone display, which contains the time, date, and primary extension. A service cannot overwrite the bottom line of the display, which contains soft key definitions. The pane that displays the service sits flush with the left side of the display, and enough of the right side of the display remains intact to ensure that users can see the status of phone lines.
Note
CiscoIPPhone XML Objects
Creating interactive service applications proves relatively easy once you understand the XML objects that are defined for Cisco IP Phones and the behavior that each object generates.
Regarding services, understand that the phone does not have any concept of a state when it loads an XML page. Cisco IP Phones can use HTTP to load a page of content in many different places, starting when the services button is pressed. Regardless of what causes the phone to load a page, the phone always behaves appropriately once it loads a page.
Appropriate behavior depends solely on the type of data that has been delivered in the page. This section of the document discusses the supported XML display types and how they work with Cisco IP Phones.
The web server must deliver the XML pages with a MIME type of text/xml. The exact mechanism required varies according to the type of web server that you are using and the server side mechanism that you are using to create your pages; for example, static files, JavaScript, CGI, and so on.
See "MIME Type and Other HTTP Headers" for more information.
The following sections provide definitions and descriptions of each CiscoIPPhone XML object:
CiscoIPPhoneMenu
A menu on the phone comprises a list of text items, one per line. Users choose individual menu items using the exact same mechanisms that is used for built-in menus in the phone, such as those seen in the Cisco IP Phone settings pages.
Definition
<CiscoIPPhoneMenu><Title>Title text goes here</Title><Prompt>Prompt text goes here</Prompt><MenuItem><Name>The name of each menu item</Name><URL>The URL associated with the menu item</URL></MenuItem><SoftKeyItem><Name>Name of soft key</Name><URL>URL or URI of soft key</URL><Position>Position information of the soft key</Position></SoftKeyItem></CiscoIPPhoneMenu>
Note
The XML format allows you to specify a title and prompt that are used for the entire menu, followed by a sequence of MenuItem objects. Cisco IP Phones allow a maximum of 100 MenuItems. Each MenuItem includes a Name and an associated URL.
When a menu is loaded, the phone behaves exactly the same as for built-in phone menus. The user navigates through the list of menu items and eventually chooses one using either the Select soft key or the DTMF keys.
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) associated with the menu item.
CiscoIPPhoneText
The CiscoIPPhoneText XML object 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. The Cisco IP Phone firmware controls all other pagination and wordwrap issues.
Note
Definition
<CiscoIPPhoneText><Title>Title text goes here</Title><Prompt>The prompt text goes here</Prompt><Text>The text to be displayed as the message body goes here</Text><SoftKeyItem><Name>Name of soft key</Name><URL>URL or URI of soft key</URL><Position>Position information of the soft key</Position><SoftKeyItem></CiscoIPPhoneText>Two optional fields can appear in the XML message:
•
•
Many XML objects that are described in this document also have Title and Prompt fields. These fields normally behave identically to behavior described in this section.
The display shown in Figure 3 provides an example of a text display. The title appears at the top above the text.
Note
Note
When normal text displays, the numbers do not display on the left side of the screen, but the navigation capability still exists. So, a carefully written text service display can take advantage of this capability.
CiscoIPPhoneInput
When a Cisco 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. Figure 5 shows a sample display that is receiving input from a user.
Figure 5 Sample User Input Display
Definition
<CiscoIPPhoneInput><Title>Directory title goes here</Title><Prompt>Prompt text goes here</Prompt><URL>The target URL for the completed input goes here</URL><InputItem><DisplayName>Name of the input field to display</DisplayName><QueryStringParam>The parameter to be added to the target URL</QueryStringParam><DefaultValue>The default display name</DefaultValue><InputFlags>The flag specifying the type of allowable input</InputFlags></InputItem><SoftKeyItem><Name>Name of soft key</Name><URL>URL or URI of soft key</URL><Position>Position information of the soft key</Position><SoftKeyItem></CiscoIPPhoneInput>The Title and Prompt tags in the object delimit text that is used in the same way as the identical fields in the other CiscoIPPhone XML objects.
The URL tag delimits the URL to which the input results are sent. The actual HTTP request sent to this server specifies the URL with a list of parameters appended to it as a query string. The parameters include Name/Value pairs, one for each input item.
Note
The InputItem tag delimits each item in the list. The number of InputItems must not exceed five. Each input item has a DisplayName, which is the prompt written to the display for that particular item. Each item also has a QueryStringParam, which is the name of the parameter appended to the URL when it is sent out after input is complete. Each input item can also use the DefaultValue tag to set the default value to be displayed.
The final item for each input item comprises a set of InputFlags. The following table describes the input types that are currently defined.
Soft Keys
During text entry, Cisco IP Phones display soft keys to assist users with text entry. The soft key names are as follows:
Users can navigate between fields with the vertical scroll button that is used to navigate menus, and so on.
CiscoIPPhoneDirectory
The phone actually incorporated the CiscoIPPhoneDirectory XML object to support the Directory operation of Cisco IP Phones. Because the functionality already exists in the phone, phone service application developers have it available as well. Figure 6 shows how an XML CiscoIPPhoneDirectory object displays on the phone.
Figure 6 CiscoIPPhoneDirectory Object Display Sample
Definition
<CiscoIPPhoneDirectory><Title>Directory title goes here</Title><Prompt>Prompt text goes here</Prompt><DirectoryEntry><Name>The name of the directory entry</Name><Telephone>The telephone number for the entry</Telephone></DirectoryEntry><SoftKeyItem><Name>Name of soft key</Name><URL>URL or URI of soft key</URL><Position>Position information of the soft key</Position><SoftKeyItem></CiscoIPPhoneDirectory>
Note
The Title and Prompt tags in the XML object have the usual semantics. A single CiscoIPPhoneDirectory object can contain a maximum of 32 DirectoryEntry objects. If more than 32 entries must be returned, use multiple CiscoIPPhoneDirectory objects in subsequent HTTP requests.
Custom Directories
You can use the "URL Directories" enterprise parameter and CiscoIPPhone XML objects to display custom directories.
The Cisco CallManager enterprise parameter "URL Directories" points to a URL that returns a CiscoIPPhoneMenu object that extends the directories menu. The request for "URL Directories" must return a valid CiscoIPPhoneMenu object, even if has no DirectoryEntry objects.
You must use the following optional objects, if used, in the order in which they are listed:
•
•
•
You can omit the CiscoIPPhoneInput or CiscoIPPhoneText objects. You can display multiple CiscoIPPhoneDirectory objects by specifying an HTTP refresh header that points to the URL of the next individual directory object, which the user accesses by pressing the Next soft key on the phone.
CiscoIPPhoneImage
Cisco IP Phones include a bitmap display with a 133 x 65 pixel pane that is available to access services. Each pixel includes four greyscale settings. A value of three (3) displays as black, and a value of zero (0) displays as white.
Note
The CiscoIPPhoneImage XML type lets you use the Cisco IP Phone display to present graphics to the user. Figure 4 shows an example of how this looks on the current release of the Cisco IP Phone.
Definition
<CiscoIPPhoneImage><Title>Image title goes here</Title><Prompt>Prompt text goes here</Prompt><LocationX>Position information of graphic</LocationX><LocationY>Position information of graphic</LocationY><Width>Size information for the graphic</Width><Height>Size information for the graphic</Height><Depth>Number of bits per pixel</Depth><Data>Packed Pixel Data</Data><SoftKeyItem><Name>Name of the soft key</Name><URL>URL of soft key</Name><Position>Numerical position of the soft key</Position><SoftKeyItem></CiscoIPPhoneImage>The CiscoIPPhoneImage object definition includes two familiar elements: Title and Prompt. These elements serve the same purpose as they do in the other CiscoIPPhone XML objects. The Title displays at the top of the page, and the Prompt displays at the bottom.
Use LocationX and LocationY to position the graphic on the phone display. Position the upper, left corner of the graphic at the pixel defined by these two parameters. Setting the X and Y location values to (0, 0) positions the graphic at the upper, left corner of the display. Setting the X and Y location values to (-1, -1) centers the graphic in the services pane of the phone display.
Self-explanatory values include Width and Height. If the values specified do not match up properly with the pixel stream specified in the Data field, unpredictable and generally incorrect results occur.
Depth specifies the number of bits per pixel. Cisco IP Phones support a maximum value of 2. A bit depth of 1 is black and white.
The Data tag delimits a string of hexadecimal digits that contain the packed value of the pixels in the display. In the Cisco IP Phone, each pixel comprises only four possible values, which means that you can pack four pixels into a single byte. A pair of hexadecimal digits represents each byte.
Figure 7 provides an example of the mechanics of pixel packing. Scanning from left to right in the display, the illustration shows the process for packing consecutive pixel values of 1, 3, 2, and 0. First, the pixels get converted to 2-bit binary numbers. Then, the binary pairs get re-ordered in sets of four to create a single re-ordered byte, which two hexadecimal digits represent.
Figure 7 Packed Pixel Translation Example
The following XML code defines a CiscoIPPhoneImage object that displays the sequence of pixels shown in Figure 7 as a graphic positioned at the center of the phone display:
<CiscoIPPhoneImage><Title/><LocationX>-1</LocationX><LocationY>-1</LocationY><Width>4</Width><Height>1</Height><Depth>2</Depth><Data>2D</Data><Prompt/></CiscoIPPhoneImage>The graphic display comprises a contiguous stream of hexadecimal digits, with no spaces or other separators. 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.
Tip
This includes the title area. If the title is to be hidden, the graphic must be large enough to cover it.
CiscoIPPhoneGraphicMenu
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. For example, users might prefer to have their choices presented in a non-ASCII character set such as Kanji or Arabic. Figure 2 shows a graphic menu on a Cisco IP Phone.
In these cases, the system presents the information as a bitmap graphic. The user then enters a menu selection by using the DTMF keypad to enter a number.
Definition
<CiscoIPPhoneGraphicMenu><Title>Menu title goes here</Title><Prompt>Prompt text goes here</Prompt><LocationX>Position information of graphic</LocationX><LocationY>Position information of graphic</LocationY><Width>Size information for the graphic</Width><Height>Size information for the graphic</Height><Depth>Number of bits per pixel</Depth><Data>Packed Pixel Data</Data><MenuItem><Name>The name of each menu item</Name><URL>The URL associated with the menu item</URL></MenuItem><SoftKeyItem><Name>Name of soft key</Name><URL>URL of soft key</URL><Position>Numerical position of the soft key</Position><SoftKeyItem></CiscoIPPhoneGraphicMenu>Menu items in the graphic menu have a name, just like the text menu counterparts. Although the name does not display to the user, it still performs a function. The name of the menu item provides the default title used when the URL for the chosen item is loaded. If the loaded page has a title of its own, the phone uses that title instead.
The XML tags in GraphicMenu use the tag definitions for CiscoIPPhoneImage and CiscoIPPhoneMenu. Although the semantics of the tags are identical, you can have only 12 MenuItem objects in a CiscoIPPhoneGraphicMenu object. See "CiscoIPPhoneMenu" and "CiscoIPPhoneImage" for detailed descriptions.
CiscoIPPhoneIconMenu
Icon menus serve the same purpose as text menus: they allow a user to select a URL from a list. Use icon menus in situations when you want to provide additional visual information to the user to show the state or category of an item. Having a read and unread icon in a mail viewer serves as an example. The icons can convey the message state with the icon.
Figure 8 shows an IconMenu on a Cisco IP Phone.
Figure 8 IconMenu on a Cisco IP Phone Sample
In these cases, the system presents the information as a bitmap graphic to the left of the menu item text. The user selects menu items that are the same as a CiscoIPPhoneMenu object.
Definition
<CiscoIPPhoneIconMenu><Title>Title text goes here</Title><Prompt>Prompt text goes here</Prompt><MenuItem><IconIndex>Indicates what IconItem to display</IconIndex><Name>The name of each menu item</Name><URL>The URL associated with the menu item</URL></MenuItem><SoftKeyItem><Name>Name of soft key</Name><URL>URL or URI of soft key</URL><Position>Position information of the soft key</Position></SoftKeyItem><IconItem><Index>A unique index from 0 to 9</Index><Height>Size information for the icon</Height><Width>Size information for the icon</Width><Depth>Number of bits per pixel</Depth><Data>Packed Pixel Data</Data></IconItem></CiscoIPPhoneIconMenu>The XML tags in IconMenu use the tag definitions for CiscoIPPhoneImage and CiscoIPPhoneMenu. Although the semantics of the tags are identical, you can only have 32 MenuItem objects in a CiscoIPPhoneIconMenu object. See "CiscoIPPhoneMenu" and "CiscoIPPhoneImage" for detailed descriptions.
CiscoIPPhoneExecute
The CiscoIPPhoneExecute object differs from the other CiscoIPPhone objects. You use this object to push a request to the phone via its web server. You must use the HTTP POST method to submit the object to the phone.
You post the CiscoIPPhoneExecute object to a case-sensitive URL. The URL http://x.x.x.x/CGI/Execute, replaces the x.x.x.x with the IP address of the destination Cisco IP Phone. The form that you post should have a case-sensitive form field name called "XML" that contains the XML object that you are posting. You can post multiple requests in a single object and receive a ResponseItem for each ExecuteItem.
When posting a CiscoIPPhoneExecute object to a phone you must provide basic HTTP authentication information with the POST. The credentials that you provide must be that of a user in the global directory with a device association with the target phone. If the credentials are invalid, or the Authentication URL is not set properly in the Cisco CallManager administration, the phone will return a CiscoIPPhoneError with a value of 4 (Authentication Error).
Note
Definition
<CiscoIPPhoneExecute><ExecuteItem URL="the URL or URI to be executed"/><CiscoIPPhoneExecute>CiscoIPPhoneResponse
ResponseItems exist for all ExecuteItems that you send. The order differs according to completion time and the execution order is not guaranteed. The URL attribute specifies the URL or URI that was sent with the request. The Data attribute contains any special data for the item. 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.
Definition
<CiscoIPPhoneResponse><ResponseItem Status="the success or failure of the action" Data="the information returned with the response" URL="the URL or URI specified in the Execute object"/><CiscoIPPhoneResponse>CiscoIPPhoneError
The following list gives possible CiscoIPPhoneError codes:
•
•
•
•
Definition
<CiscoIPPhoneError Number="x"/>CiscoIPPhone XML Object Quick Reference
Table 1 provides a quick reference of the CiscoIPPhone XML objects and the definitions associated with each.
XML Considerations
The XML parser in Cisco 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.
Note
Mandatory Escape Sequences
By XML convention, the XML parser also requires that you escape a few special characters. Table 2 lists characters and their escape values.
.
Table 2 Escape Sequences for Special Characters
&
Ampersand
&
"
Quote
"
'
Apostrophe
'
<
Left angle bracket
<
>
Right angle bracket
>
Escaping text can be tedious, but some authoring tools or scripting languages can automate this task.
Custom Soft Keys
Cisco IP Phones now have the ability to receive custom soft keys with the CiscoIPPhone objects. Soft keys can have URLs or URIs associated with them. Newly created URIs allow you to call the native softkey event with a custom soft key.
XML Objects Used With Nonstreaming URIs
This section describes objects that you use in what context with nonstreaming URIs and what, if any, comprise the object order requirements.
The following list contains the XML objects that can be used:
•
•
•
•
•
•
•
URIs for Pressing Buttons on the Phone
The Key URI allows a programmer to send an event that a key has been pressed. The same event is fired as when the physical buttons are pressed. The phone hook switch is not exposed since this would cause the hardware to be out of sync with the software.
Note
Example 1 Key:Soft1
If the soft key set is changing and disabled while the event is being processed, the request is discarded.
Verification of available soft keys is achieved with the QA web pages provided by the phones web server that indicate the active soft key set.
Key
URI Format:
Key:nWhere
n is a Key name. The following is a complete listing of the Key URIs:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
URIs for Invoking SoftKey Functionality
An XSI developer can execute native soft key functionality when the phone executes a SoftKey URI. The primary purpose for the SoftKey URI is to allow developers the ability to customize soft key names and layout in the Services and Directories windows while retaining the functionality that the soft keys provide.
SoftKey URIs work in menu items, soft key items, and execute items that are pushed to the phone. The SoftKey URIs use is limited to the objects on which they natively occur on the phone.
SoftKey
URI Format:
SoftKey:nWhere
n is one of the following soft key names:
•
•
•
•
•
•
•
•
•
•
•
Valid soft key actions for each XSI object type follow. The URI invokes the native functionality that each key possesses in the given object context.
•
–
–
•
–
–
•
–
–
•
–
–
•
–
–
•
–
–
–
–
•
–
–
–
–
Generic URIs that can be used in place of URLs follow:
•
•
QueryStringParam URI
The QueryStringParam URI allows an application developer to collect more information from the user with less interaction. When the user performs an action with a soft key, you can either append a query string parameter to the URL of the highlighted MenuItem or append the query string parameter from the MenuItem to the URL of the soft key.
URI Format:
QueryStringParam:dWhere
d = the data to be appended to a corresponding URL.
Example 2 QueryStringParam URI in a CiscoIPPhoneMenu object
<CiscoIPPhoneMenu><Title>Message List</Title><Prompt>Two Messages</Prompt><MenuItem><Name>Message One</Name><URL>QueryStringParam:message=1</URL></MenuItem><MenuItem>Name>Message Two</Name><URL>queryStringParam:message=2</URL></MenuItem><SoftKeyItem><Name>Read</Name><URL>http://server/read.asp</URL></SoftkeyItem><SoftKeyItem><Name>Delete</Name><URL>http://server/delete.asp</URL></SoftkeyItem></CiscoIPPhoneMenu>Example 2 shows how to use the QueryStringParam URI in a CiscoIPPhoneMenu object. The CiscoIPPhoneMenu object has two MenuItems with QueryStringParam URIs. If the user selects the MenuItem(s) with the numeric keypad, the cursor moves to that entry but nothing executes because the values are QueryStringParam URIs.
If the user presses either of the custom soft keys, the currently highlighted MenuItem URI value is appended to the soft key URL that was pressed and requested from the web server.
If you highlight the first MenuItem and press the Read soft key, the phone generates the following URL:
http://server//read.asp?message=1
Example 3 Selecting an Item with Numeric Keypad calls the URL
<CiscoIPPhoneMenu><Title>Message List</Title><Prompt>Two Messages</Prompt><MenuItem><Name>Messae One</Name><URL>http://server/messages.asp?message=1</URL></MenuItem><MenuItem><Name>Messae Two</Name><URL>http://server/messages.asp?message=2</URL></MenuItem><SoftKeyItem><Name>Read</Name><URL>QueryStringParam:action=read</URL></SoftKeyItem><SoftKeyItem><Name>Delete</Name><URL>QueryStringParam:action=delete</URL></SoftKeyItem></CiscoIPPhoneMenu>The Cisco IP Phones allow you to implement the QueryStringParam URI in either manner. However, Example 3 is not as efficient as Example 2. Choose the best way to perform the action based on your applications needs.
Example 3 does have a slight advantage in that if the user selects an item with the numeric keypad, the URL is called. This would allow you to invoke some default behavior such as to read the message in the example. By highlighting the first message and pressing the Read soft key, the phone creates the following URL:
http://server/messages.asp?message=1&action=read
Using the QueryStringParam URI reduces the size of the XML objects that you generate by not having to repeat redundant portions of a URL in every MenuItem.
URIs to Control RTP Streaming
It is possible to invoke RTP streaming via URIs in services. You can instruct the phone to transmit or receive an RTP stream with the following specifications.
The supported format of the RTP stream follows:
•
•
RTPRx
The RTPRx URI instructs the phone to receive a Unicast RTP stream or to stop receiving Unicast or Multicast RTP streams.
URI Formats:
RTPRx:i:pRTPRx:StopWhere
i is the IP Address from which the stream is coming
p is the TCP port on which to receive the RTP stream. This must be an even port number within the decimal range of 20480 to 32768. If no port is specified, the phone chooses a port and returns it when initiated by a push request.
Stop is the parameter that will stop any active RTP stream from being received on channel one.
RTPTx
The RTPTx URI is used to instruct the phone to transmit a Unicast RTP stream or to stop transmitting Unicast or Multicast RTP streams.
URI Formats:
RTPTx:i:pRTPTx:StopWhere
i is the IP Address to transmit an RTP stream to.
p is the TCP port on which to transmit the RTP stream. This must be an even port number within the decimal range of 20480 to 32768.
Stop is the parameter that will stop any active RTP stream from being transmitted on channel one.
RTPMRx
The RTPMRx URI instructs the phone to receive a Multicast RTP
URI Format:
RTPMRx:i:pWhere
i is the Multicast IP Address from which to receive an RTP stream.
p is the Multicast TCP port from which to receive the RTP stream. This must be an even port number within the decimal range of 20480 to 32768.
RTPMTx
The RTPMTx URI instructs the phone to transmit a Multicast RTP stream.
URI Formats:
RTPTx:i:pWhere
i is the Multicast IP Address to transmit an RTP stream to.
p is the Multicast TCP port on which to transmit the RTP stream. This must be an even port number within the decimal range of 20480 to 32768.
Miscellaneous URIs
This section describes the following miscellaneous URIs:
•
•
•
Init
The Init URI allows an application to initialize a feature or data with the argument that is passed with the URI.
URI Format:
Init:oWhere
o is the Object name.
Valid object name:
CallHistory—When the phone encounters an Init:CallHistory URI, it clears the internal call history logs that are stored in the phone. This initializes Missed Calls, Received Calls, and Placed Calls.
Dial
The Dial URI initiates a new call to a specified number. The Dial URI invokes when it is contained in a menu item, the menu item is highlighted, and the device is taken off hook.
Activate the Dial URI by one of the following:
•
•
•
•
•
•
URI Format:
Dial:nWhere
n is the number dialed (such as Dial:1000).
EditDial
The EditDial URI initiates a new call to a specified number. The EditDial URI invokes when it is contained in a menu item, the menu item is highlighted, and the device is taken off hook.
Activate the EditDial URI by one of the following:
•
•
•
•
•
•
URI Format:
EditDial:nWhere
n is the number dialed (such as EditDial:1000).
Play
The Play URI downloads an audio file from the TFTP server and plays through the phone speaker. This is the same mechanism that is used to play ring files. The format of the files is the same. You could use the Play URI to play files that are in the Ringlist.xml or those that are not.
If you want to achieve a unique audible notification, use a file that is not available from the Ringli
Guest
