Here is a sample of a simple Deck. It is made up of an XML Prolog section containing the standard XML header information and a <wml> body containing one or more <card> tags.

No, the <do> tag's {optional="true|false"} attribute is not implemented.

Example:

<do type="prev" name="prev1" label="prev1" optional="true"> <prev/> </do>

By definition, when the optional attribute is set to true in a <do> tag, that particular <do> tag is not supposed to be displayed. But, in this case, the <do> tag is displayed and the optional attribute is ignored while parsing.

There are several reasons why you can get this error. The following list gives some of the most common:

• There is a syntax error somewhere in your WML. Remember that WML is far more strict and less forgiving than HTML. WML files are case sensitive and type attributes must be in lower case. Also, all tags must be closed with a slash ( /) like this:
  <example/>
  or followed by a closing tag like this:
  <example>close the tag on your way out </example>.
  WML also has much stricter rules governing the nesting of tags.
• Make sure that your WML is consistent with the WML supported by the Web Browser. The Web Browser does not support every tag and attribute as proposed by the Open Mobile Alliance (http://www.wapforum.org/). Consult the "4600 Series IP Telephone Interfaces API Guide" or the "Avaya one-X Deskphone Edition for 9600 Series IP Telephones Application Programmer Interface (API) Guide"which describes the WML tags and attributes supported by the 4600 IP Telephone's Web Browser. This document is available on the DevConnect web site, http://devconnect.avaya.com/ .
• Make sure you search this FAQ for any know issues with the Web Browser's handling of WML.
• Check to see that the WMLHOME setting in the 46xxsettings.txt or 96xxsettings.txt file is a valid WML file
• Check to see that the WMLPROXY setting in the 46xxsettings.txt or 96xxsettings.txt file is correct
• Check to see that the WMLPORT setting in the 46xxsettings.txt or 96xxsettings.txt file is the correct port
• Check to see that the DNSSRVR setting in the 46xxsettings.txt or 96xxsettings.txt file is set to a valid DNS server
• If the 46xxsettings.txt or 96xxsettings.txt settings above are valid, check to see that the TFTP or HTTP server that the IP phone uses to get this file is running.

Check to see tht the WMLHOME URL page exists on the server.

Check to see that the WMLHOME value in the 46xxsettings.txt file is a valid URL

The "Web" softkey only appears if WMLHOME is defined in the 46xxsettings.txt or 96xxsettings.txt file. If the WMLHOME parameter is missing or empty then the "Web" softkey does not appear on the screen.

If the WMLHOME setting is valid, check to see that the TFTP or HTTP server that the IP phone uses to get this file is running.

No. All <onevent> attributes such as "ontimer", "onenterbackward", "onenterforward", are not functional when used inside the <template> tag. Any action implemented by these events will not be carried out. Please use alternate form to execute these events outside of the <template> tag.

No. The CSS background color style for the <br/> tag is not supported. That is the <br/> tag will inherit color information from the parent tags such as <p> tag.

That sample is not coded correctly. The <timer> tag can NOT be inside the <onevent> tag.

The example in the API Guide is:

The correct version is:

The 'accesskey' attribute is supported only with the < a > tag and the < anchor > tag. The 'accesskey' attribute cannot be used along with the < go > tag because it is not a valid attribute for the < go > tag. For more information, refer to the "Avaya one-X Deskphone Edition for 9600 Series IP Telephones Application Programmer Interface (API) Guide", or the "Application Programmer Interface (API) Guide - 4600 Series".

Push is the ability of an external application to send content to the telephone using the HTTP protocol without the user requesting it. Content can be pushed to the phone as a text message, WML Web page, or an audio stream through the handset or speaker. The Web Browser interface requires users to "Pull" data from an application, such as when a user clicks a link to access information. By using the Push API, an application can spontaneously deliver information to the telephone without depending on user input. In addition, there is a Subscription Push type which causes the phone to re-subscribe with its Subscription Servers. The Subscription service allows external applications to dynamically become aware of the IP Telephones and build databases of users.

There are three types of Push Messages: Topline, Display and Audio. A Topline push sends a single line of text to the top line of the IP phone screen. A Display push send content such as WML pages, images, click-to-dial links, and forms. Any Web content supported by the browser can be pushed. The Audio push type sends one-way RTP audio streams.

All the Push types can be configured to have optional alerts sound upon their arrival. The Push API supports the notion of message priority.

The Push API employs standards based interfaces, including HTTP, XML, WML, and standard Web servers. There are no proprietary servers, languages or protocols used. This helps make the Push API easy to learn and support as no special skills are required.

A Push Message consists of a very simple XML message sent to the IP phone using an HTTP Post command.

The Push interface can be used to:

• Broadcast company news
• Send meeting reminders with click-to-dial conference bridge numbers
• Stream music, such as wake-up alarms in hotel rooms
• Stream audio announcements
• Send news information such as stock prices
• Broadcast weather alerts
• Build databases to target information to an individual or groups of phones

Here is the generic template for a Push Message:

The Push Message has atttributes for how many alert "pings" to sound, the priority and the type of Push. It contains a URL for the location of the actual Push Content, i.e., the information to display on the phone.

For example, to send a high priority Topline Push with 3 alerts to an IP phone, an application would send an HTTP Post request to the URL of the phone (http://<IP_Address_of_the_telephone>/forms/push) with the following XML message as the value of the HTTP POST pre-defined variable called "XMLData":

Where the text to display is contained in the Push Content file, filename.wml on the server, trusted_push_server. The phone retrieves the Push Content for display.

Please see the "4600 Series IP Telephone Interfaces API Guide" or the "Avaya one-X Deskphone Edition for 9600 Series IP Telephones Application Programmer Interface (API) Guide" for a full description of the Push API.

For a Topline or Audio push, the Push Content file is a simple XML file.

For example, a Push Content file for a Topline Push is shown below.

For a Display type push, the Push Content is a WML file where the entire range of features of an IP Telephone's Web browser can be used.

Please see the "4600 Series IP Telephone Interfaces API Guide" or the "Avaya one-X Deskphone Edition for 9600 Series IP Telephones Application Programmer Interface (API) Guide" for a full description of the Push API

The Avaya 4600 Series and the Avaya 9600 Series IP telephones support a subscription service, whereby they provide a set of identifying values (such as IP address) to subscription servers. This allows intelligent applications to dynamically build a database of all IP telephones. The subscription occurs automatically when the IP phone registers with the media server (Avaya Communication Manager). The subscription Service makes the administration of IP phones and their associated applications much easier by automating the discovery process.

Once an application builds a database of information about all telephones in a network, it can target Push Content to specific phones or groups of phones.

The phone makes the following values known to the trusted subscription service server(s):

• IP Address of the Phone
• User's Extension
• MAC Address
• Set ID, a fixed eight-character model number

An IP phone can only be logged in to a single extension at any given time. In order for it to log in as a different extension, it has to log out first, using the 'Options' button on the IP phone and then selecting 'Logoff'.

4625 and 4621 IP phones have the same form factor (that is, same size, same number of buttons and same layout of buttons). The only difference between them is the screen. The 4625 IP phone has a VGA backlit display supporting 256 colors and is capable of displaying JPEG format files. The comparison between the various 4600 Series IP telephones can be found at: http://support.avaya.com/elmodocs2/4620/ Web_Browser_faq_2.2_2.5.pdf.

There is no provision in JTAPI, TSAPI or DMCC to accomplish this, but this can be achieved using RTCP Monitoring. Configure the IP address of the server that will receive RTCP information from Avaya Communication Manager (CM) on the 'ip-network-region' page. The IP phones will obtain the RTCP server settings from the Avaya CM based on the IP-network-region that it belongs to. When the IP phone is in a call, it will send RTCP information directly to the RTCP server. This is the way to check if there is actual audio between two IP end-points as the actual packet loss for the call can be monitored.

By default, an extension is configured with three call appearances - the first two for answering calls and the third reserved for transferring/conferencing calls. This can be changed using the 'change station xxxx' form on the Communication Manager (CM). Similarly, an extension can be configured with one or many bridge appearances. This allows the extension to answer calls on behalf of the extensions that have a bridge appearance. The configuration is done on the 'change station xxxx' form. A bridge appearance is programmed using the option 'brdg-appr'.

For more information, see: http://support.avaya.com/japple/css/japple?PAGE=Document&temp.bucketID=160257&temp.productID=107755&temp.documentID=300566

The 4690 IP phones use the same MIB as the rest of the 46xx series. For more information, see: http://support.avaya.com/elmodocs2/MIB/46xxmib28.txt

For 'vpnremote', there are several Application Notes available at: http://www.avaya.com/gcm/master-usa/en-us/resource/filter.htm&Filter=Type:Application%20Notes;CollectionSearch:vpnremote

The protocol used with Avaya IP Telephones includes proprietary extensions.

However, the documentation cannot be provided without a special approval. If there is an application that requires Avaya's proprietary extensions, one can contact the respective DevConnect Business Development Manager to get the necessary approval. Avaya does support connectivity to generic H.323 endpoints without the use of the proprietary extensions, but this limits the feature set that the endpoints can support.

If the Avaya IP Phone PushSDK is used for developing a sample application, then Tomcat or some other servlet container will have to be used. If the Avaya IP Phone PushSDK is not used for developing sample applications, then a server-side scripting language like PHP or VB Script can be used to develop the applications. In this case, Tomcat would not be required, i.e., any other web server like Apache or Microsoft IIS can be used.

For more information, refer to the "Avaya one-X Deskphone Edition for 9600 Series IP Telephones Application Programmer Interface (API) Guide", or the "Application Programmer Interface (API) Guide - 4600 Series" and the documentation for the Avaya IP Phone PushSDK Version 1.0 available at the Devconnect Web site: www.avaya.com/devconnect.

Refer the following link for downloading the images of all Avaya products:

http://www1.avaya.com/enterprise/photo_library/

No, it is not possible to render an image and text together on a single line of the Avaya IP Telephone.

In the '46xxsettings.txt' file, there is an area called DISPLAY SETTINGS which allows setting logos as the display background for Avaya IP Telephones. Refer the Avaya 4600 Series IP Telephone Administrators Guide for additional information on this parameter.

The 'PUSHCAP' parameter is used for the 'Push' capabilities setting. 'PUSHCAP' consists of 3 bits (each 0, 1, or 2). The rightmost bit controls the Top Line Push mode. The middle bit controls the Web Browser Push mode. The leftmost bit controls the Audio Push mode.

When 'PUSHCAP' is set to 000, all Push modes are disabled. When 'PUSHCAP' is set to 111, barge in only is allowed in all Push modes. When 'PUSHCAP' is set to 222, both barge in and normal pushes are allowed in all Push modes.

Example: SET PUSHCAP 111

To enable SNMP on Avaya IP Telephones, follow the steps below:

• Edit the '46xxsettings.txt' file
• Add the following line under the SNMP SETTINGS section:"SET SNMPSTRING public"
• Reset IP Telephone to download the changed settings file (Mute-R-E-S-E-T).