Level: Introductory Veronika Megler (vmegler@us.ibm.com), Consulting IT Architect, IBM eServer pSeries Solutions Development
01 Jul 2002 Wireless developers have long been using XML-derived technologies to build applications for handheld devices with limited interface and storage capabilities. In this article, Veronika Megler shows you a new arena for those skills: the office telephone handset. With improvements in Voice over IP (VoIP) technologies, many enterprises will soon be using the phone that sits on an employee's desk as an application platform. Here, you'll walk through an example and see how you can use XML to build simple and useful small-footprint applications.
Voice over IP (VoIP) technologies use an IP-based network to make telephone calls and provide other capabilities that would normally be provided over the public switched telephone network (PSTN) or an enterprise private branch exchange (PBX) network. For some years, VoIP has been the reputed dream about to be realized. Now, however, new products are reaching the marketplace that are not only production-ready, but are also priced low enough to compete with the more traditional telephony solutions. When thought of in terms of end-to-end voice transmitted over an IP network, VoIP has had its ups and downs. Much of VoIP's original buzz centered around computer/telephony integration; the technology was sometimes represented as one that allows users to make calls from a computer, over the Internet, using the computer's built-in microphone, rather than having to use a telephone. However, many noted that concerns about usability, quality of service, and the ability to manage bandwidth and reliability would need to be resolved before this vision could become a pervasive reality. While Internet phone calls are still interesting for hobbyists, it's generally agreed that the Internet is not an appropriate platform for enterprise or carrier VoIP networks. Over the past few years, VoIP has been identified as a good solution for specific problems -- and the number of areas where it is a viable solution continues to multiply:
- In the wireless telephone space, VoIP is an established phenomenon. Packet-based networks, such as the CDMAOne network used by Verizon, are IP-based. The 3G networks that are being rolled out in Japan and Europe are, in their essence, IP-based networks that allow voice and data to be merged in a single infrastructure.
- Calls whose backbone is run over the Internet and that terminate at telephones at both ends are now a well-established business offering. Net2Phone and similar companies provide a phone number to call in a local city, then provide long distance and overseas phone service over the Internet at rates I've not been able to match with any traditional long distance carrier.
- Perhaps the newest area of VoIP interest is the enterprise telephone solution, which provides an IP-based network within an enterprise and a voice-to-VoIP interface at the boundary of the organization to connect that IP network to the outside world. Such offerings are the focus of this article.
VoIP in the enterprise
In the wired world, the promise of the VoIP technology is that it can replace a typical organization's two separate network infrastructures -- the data and the voice networks -- with a single, IP-based network. A telecommunications carrier can save money with such a simplified infrastructure, since it need only maintain a single set of cables, switches and other equipment, and can run the network with common network management software. From the carrier's point of view, a packet-based network for voice is inherently more efficient than a network that provides a dedicated channel to each caller. Within the average enterprise, separate data and voice networks still reign supreme. However, maintaining only one network is just as appealing to an enterprise as it is to a carrier -- assuming, of course, that the upgrade costs aren't prohibitive. From the enterprise's point of view, switching to an internal VoIP network has an additional advantage: the external telecom provider doesn't need to change its offerings, but can continue to provide regular PSTN trunk lines or T1s to the enterprise. Switching to a national VoIP-enabled carrier is not required. So how does it work? The wires from the carrier providing telephone service come into the enterprise, just as they do today; most probably, for any reasonably sized enterprise, they arrive as T1 trunk lines. A VoIP gateway, such as a Cisco 2600 VoIP router, is then installed at the point where the trunk lines connect into the enterprise, and acts as a protocol converter between the T1 voice call protocols being used and VoIP.
Figure 1. VoIP in the enterprise
While the protocols that transmit calls over the IP-based network are pretty standardized -- IETF's RTP (Real Time Protocol, used for sending the VoIP data) and RTCP (Real Time Control Protocol, used for the control channel) -- there are multiple protocols that can be used to actually set up and tear down the telephone calls themselves. Several of the most popular ones are H.323, SIP, MGCP, and IPDC. (See the Resources section below for more information on these.) Due to the newness of some of these standards and the lack of standardization among them, products available today may also implement proprietary protocols. In addition to converting the actual voice traffic itself, the VoIP router will mediate the setup and tear-down protocols on behalf of the incoming and outgoing telephone calls. Within the enterprise, some kind of call control system or IP-based PBX provides phone system management services, such as the ability to define which IP address is associated with a particular telephone number. These systems are often called by the generic name soft switches, and are generally separate from the server providing the VoIP router functions. A soft switch replaces the old hardware- and patch-panel-based phone switches with a software-driven server. These servers are now often based on standard operating systems, such as Linux, Unix, or Windows 2000. The soft switch provides an interface by which an administrator can quickly and easily configure the phones and their options. Thus, a telephone handset can be moved from cubicle to cubicle and preserve its phone number with no intervention by network technicians or administrators. IP phones are then added into this environment. The higher-end phones have screens and programmable functions, just like non-IP enterprise high-end phones. The phone manufacturers generally provide the option of adding data-based functions -- such phones can view call logs, look up directories, and display instructions on how to perform phone magic, like adding a fourth person to a three-way conference call. As with current wireless phones, voice is just another kind of data as far as the phone is concerned; however, from the viewpoint of the user, voice and data are separate modes that the phone can switch between. The user can invoke the functions to make this switch, or the phone can do so itself under programmatic control. The picture we're drawing is starting to include a lot of functions available on a wireless phone -- but we're talking about a device with the luxury of a larger screen. So, the next question becomes: How do we integrate our enterprise applications with this telephone?
An example environment
There are currently many different implementation options, with many players providing products. Since the VoIP router, call control system, and IP phones must interoperate and must all be configured to support the same protocol, any protocol decision you make will limit the vendors and products that you can use. The example I'll outline here is based around the Cisco product suite, since there are two demonstration laboratories in my building complex -- the Linux for Service Providers Laboratory, and IBM Global Services' VoIP demonstration lab -- with this equipment installed. The two sites have similar configurations, as shown in Figure 2.
Figure 2. Our current installation
In our case, our VoIP router/media gateway sits behind the company's PBX, and the PBX administrator has assigned us a set of telephone numbers that we can use for demonstrations. We are currently running Cisco's CallManager as our call control system. We use CallManager to assign telephone numbers to specific telephones, manage the services available to each phone, and otherwise manage the IP phone network. CallManager assigns each phone an IP address, via either DHCP or a static configuration, and updates its central directory with information about each component and its configuration. The CallManager software runs on Windows NT on a rack-mounted Intel-based server. A copy of Microsoft IIS installed on the server provides a browser interface. Cisco's second-generation VoIP phones include the Cisco 7940 and 7960. These phones connect directly to a 10/100BaseTx Ethernet network via an RJ-45 interface. The Cisco 7960 is shown in Figure 3.
Figure 3. Cisco 7960 IP phone
Note that the date and time are shown automatically at the top of the phone's screen, as is the extension number programmed for this phone. As you can see, the extension for this particular phone is 2000. The 7940 and 7960 phones can be configured to run in one of several so-called call processing environments, or protocols, including Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), and Skinny, a proprietary protocol developed specifically for the CallManager. The banner on the phone shows the protocol that the phone is using; in Figure 3, the absence of any icon after the extension number indicates that we are running Cisco's Skinny protocol. Note that there are four keys just under the screen; these can be programmed and are known as soft keys. Also, there is a rocker key under the third soft key, which can be used to move a cursor up or down the screen or menu currently displayed. I'll talk more about these keys later. Both the 7940 and 7960 phones have a Services key just below and to the left of the key labeled "i," on the right of the phone's front panel. If Cisco's CallManager software is being used, this Services button can be reprogrammed to access customizations -- in our case, we'll be using it to access a custom application. Support for this functionality is not available with all protocols.
The Cisco IP phone: XML browser capabilities
The Cisco 7940 and 7960 IP phones include a minimal XML browser. This browser understands a subset of the HTTP protocol and a very small number of predefined XML tags. These tags can, with a little ingenuity, be used to build new applications or new interfaces to existing applications. The phone's user can interact with the display using the phone keypad and the additional buttons provided. Here are the functions that can be performed by the set of XML tags that the phones understand:
- Show a menu and select an item from it (
<CiscoIPPhoneMenu>)
- Show some text (
<CiscoIPPhoneText>)
- Accept input (
<CiscoIPPhoneInput>)
- Show phone directory entries, and allow the user to call a number associated with one of those entries (
<CiscoIPPhoneDirectory>)
- Show a picture (
<CiscoIPPhoneImage>)
- Show a menu, built using graphics (
<CiscoIPPhoneGraphicMenu>)
Cisco provides a document, "Cisco IP Phone Services Application Development Notes" (see Resources for a link), that describes these XML tags in detail. Note that the browser provides no scripting language and does not maintain state. It does not recognize <META> tags, and so cannot apply stylesheets to create the required XML. Therefore, the server must provide the appropriate XML tags. Only the HTTP GET method can be used; POST is not available. The browser provides very limited error detection. While experimenting, I became extremely familiar with the following errors:
-
XML Parse Error [4], which means "something's wrong in your XML somewhere."
-
Host not found, which means "something's wrong in the URL you coded." Usually when I encountered this, it was roughly equivalent to an HTTP 404 error.
Cisco also provides a downloadable SDK (see Resources), which consists of a number of components:
- A thorough set of sample services, ready to be deployed to a 7940/7960 phone. These are all ASP samples, written in JavaScript, and they do things like look up weather forecasts, offer currency exchange rate conversion, look up UPS rates, provide airline information, and so on. In all cases, the services obtain their information from real Internet sites. They demonstrate how you can interact with all the phone's capabilities, and are fully deployable. Prerequisites are: Microsoft IIS 4.0 or later, the SDK itself, access to the Internet, a Cisco 7940/7960 phone, and Cisco CallManager 3.1.
- A set of development tools: conversion programs for graphics, a proxy server, which is necessary to use the samples, and a service to do LDAP searches (provided as DLLs).
- A set of documentation on how to set up the sample services and use the tools.
Although Cisco CallManager contains a Microsoft IIS server, the IP Phone Services SDK documentation states that the SDK should not be installed on the Cisco CallManager server, but rather on a separate Web server. To my knowledge, there is no phone emulator available. To test the samples, you must have a real Cisco 7940 or 7960 telephone available to you.
Developing for the phone
To understand the capabilities and constraints provided by this infrastructure, I set out to build a set of simple applications that would allow me to extrapolate to any arbitrarily complex integration. This meant testing the different options on the phone, and building different combinations of functionality at the back end. In order to perform the development from my desk, I built each of these examples and performed initial testing using Internet Explorer to show the XML files. I then tested and debugged them on the Cisco IP phones. In my case, my back-end infrastructure, where I ran all the sample applications, consisted of an AIX 4.3.3 server, running IBM HTTP Server 1.3.12 (based on Apache) and IBM WebSphere Application Server 3.5.4. However, these samples should work with any HTTP server and any application server. I'll refer to my back-end server throughout the rest of this article as http://myserver. I ran the Cisco SDK on this machine too, but you don't need the SDK installed to run this article's examples. To start with, I configured the Services button on the phones to point to a URL on my Web server that I could then manipulate. To do this, I used CallManager's Administration pages to add services (i.e., URLs) to which a telephone could subscribe. The service URL can be entered by opening the CallManager Administration page and selecting Feature -> Cisco IP Phone Services from the drop-down menu. A service is added by entering the service URL in the appropriate place, including any parameters desired. In this case, I entered a URL that pointed to a dummy XML file, as follows.
http://myserver/ciscomenu.xml
|
There is also a field where you can enter an optional description for your own purposes, but CallManager does not use this anywhere. Next, I chose Update Subscriptions to rebuild the subscriptions for the phone. Once this was done, I pressed the Services button on the phone to load the given URL, and show the results of that operation on the phone screen. My next step was to configure my HTTP server to correctly serve XML files. To do so, I made sure that the following line was in Apache's mime.types file:
Then I built a menu that would allow me to point to each of my other samples, and to try out different mechanisms for passing control. I started with a minimal menu, and then added functions. The initial menu file, ciscomenu.xml, included the code in Listing 1.
Listing 1. ciscomenu.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<CiscoIPPhoneMenu>
<Title>Sample Page Title</Title>
<Prompt>Choose one of the below</Prompt>
<MenuItem>
<Name>News Flash</Name>
<URL>http://myserver/flash.txt</URL>
</MenuItem>
<MenuItem>
<Name>Weather</Name>
<URL>http://myserver/weather.xml</URL>
</MenuItem>
<MenuItem>
<Name>Caf. Menu</Name>
<URL>http://myserver/cafmenu.xml</URL>
</MenuItem>
...
</CiscoIPPhoneMenu>
|
I then placed ciscomenu.xml into the default documents directory for my HTTP server (/usr/HTTPServer/htdocs/en_US/). With all this behind me, I am now serving a static file from my HTTP server to the phone; here's how it looks after the Services button is pressed.
Figure 4. ciscomenu.xml
Note that the title appears at the top and the prompt at the bottom of the screen. If either of these is too long to fit, you will receive an XML parse error. Displaying text
CallManager automatically provides the two soft keys, Select and Exit. Choosing Exit from the main menu will cause the phone to exit the Services menu. The Select button will cause the highlighted menu option (News Flash in Figure 4) to be executed. The phone understands plain text in addition to XML tags. The phone does not understand HTML; in fact, if you attempt to display an HTML file on the phone, it will be displayed as though it were text. The News Flash menu option displays a text file (flash.txt) that contains the following:
NewsFlash (text):
Severe storm warning for local area this afternoon.
Please ensure all buildings are secured.
|
Figure 5 shows how it displays on the Cisco 7960.
Figure 5. flash.txt
Here, the Update and Exit soft keys are again provided for us. Choosing Exit will send the user back to the main menu. The Update button will cause the previous command to be reexecuted; if the file has changed in the meantime, the new file will be displayed. What's for lunch?
From the initial menu in Figure 4, pressing the 3 key, or using the rocker to move down two items to highlight the Caf. Menu item and then pressing the key under the Select button, causes the selected option to be executed. In this case, the URL points to the file cafmenu.xml, which contains the code in Listing 2:
Listing 2. cafmenu.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<CiscoIPPhoneText>
<Title>Cafeteria Menu (XML)</Title>
<Text>Today's Special: Tacos
Desert: Double Chocolate Brownies
Coffee Flavor: Amaretto
</Text>
<Prompt/>
</CiscoIPPhoneText>
|
Figure 6 shows how it looks on the telephone:
Figure 6. cafmenu.xml
Note that the Cisco browser has provided the same soft keys as before, since I have not provided any alternatives.
Adding more complexity
I added two menu items to my top-level menu, ciscomenu.xml, in order to explore additional features -- phone directory items, application server integration, and pictures. Here is the XML for the menu items added:
Listing 3. Additions to ciscomenu.xml
<MenuItem>
<Name>Personal Phone Directory</Name>
<URL>http://myserver/phone.xml</URL>
</MenuItem>
<MenuItem>
<Name>WAS Integration</Name>
<URL>http://myserver/webapp/examples/Refresh.jsp</URL>
</MenuItem>
|
Phone home
Let's take a look at the Personal Phone Directory, which demonstrates the use of the <CiscoIPPhoneDirectory> XML object. This object allows you to show a set of directory entries. When the user selects an entry from the list, the phone automatically dials the number provided as part of the directory entry. In Listing 4 I show the contents of phone.xml, which currently contains two preprogrammed phone numbers.
Listing 4. phone.xml
<CiscoIPPhoneDirectory>
<Title>Call 'em </Title>
<Prompt>Call this person: </Prompt>
<DirectoryEntry>
<Name>Husband</Name>
<Telephone>95035551234</Telephone>
</DirectoryEntry>
<DirectoryEntry>
<Name>Corporate Help Desk</Name>
<Telephone>918005551234</Telephone>
</DirectoryEntry>
<SoftKeyItem>
<Name>Dial</Name>
<URL>SoftKey:Dial</URL>
<Position>1</Position>
</SoftKeyItem>
<SoftKeyItem>
<Name>AddNew</Name>
<URL>http://myserver/AddNew.xml</URL>
<Position>2</Position>
</SoftKeyItem>
<SoftKeyItem>
<Name>Exit </Name>
<URL>SoftKey:Exit</URL>
<Position>3</Position>
</SoftKeyItem>
</CiscoIPPhoneDirectory>
|
Figure 7 shows the matching screen shot.
Figure 7. phone.xml
When the user selects Dial, the number in the highlighted entry is dialed. You'll hear the DTMF (Dual Tone Multi-Frequency; see Resources for more information) tone for the phone number and then the ringing sound, as the phone is automatically switched into speaker-phone mode. Only 32 entries can be displayed in one list; if more are needed, you'll need to break them into multiple <CiscoIPPhoneDirectory> sets, and build URLs that allow you to move between them. The browser does not maintain state of any kind. To build applications that do maintain state -- as you would probably want to do for these kinds of functions -- the state must be built into the XML that is shipped out to the phone. For example, you could code it into the URLs to be executed when an option is selected. Listing 4 also shows another new tag: <SoftKeyItem>. This tag allows you to change the functions of the soft keys, and display a label that you define above the key. The <Position> attribute identifies which of the keys will be used for this function. When I added the first soft key function, I discovered that the preset functions for the soft keys were no longer provided for me. I added them back in manually, as you can see in Listing 4. I also wanted to provide an Add New function for the user; doing so required the execution of a different XML object that would allow the phone to accept input. AddNew.xml, shown in Listing 5, asks the user to input information for a new directory entry.
Listing 5. AddNew.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<CiscoIPPhoneInput>
<Title>Add New Entry</Title>
<Prompt>Enter name, number</Prompt>
<URL>http://myserver/thanks.xml</URL>
<InputItem>
<DisplayName>Name</DisplayName>
<QueryStringParam>name</QueryStringParam>
<InputFlags>A</InputFlags>
<DefaultValue></DefaultValue>
</InputItem>
<InputItem>
<DisplayName>Number</DisplayName>
<QueryStringParam>number</QueryStringParam>
<InputFlags>T</InputFlags>
<DefaultValue>9</DefaultValue>
</InputItem>
</CiscoIPPhoneInput>
|
This example asks for two input items: the name to be assigned to the directory entry, and the number to be dialed when that entry is selected. Figure 8 shows the screenshot:
Figure 8. AddNew.xml
The <DisplayName> attribute indicates the label that will be shown on the screen for the input item, and <QueryStringParam> is the name that will be used when the browser builds the name/value pairs from this definition and the user input. The number of name/value pairs that can be used is limited to five. For both of my input fields, I limited the characters that will be accepted via the <InputFlags> attribute. <InputFlags>A</InputFlags> means that this field will only accept ASCII text; in Figure 8, the options available for the key I just pressed are shown, and I can select a different one by continuing to press the same key. If I wait a second without pressing the key again, the browser moves to the next entry position. I move to the next entry field (here, Number) by pressing the rocker key in the down direction. <InputFlags>T</InputFlags> denotes a telephone number, and this field will thus only accept DTMF digits -- i.e., #, *, and the digits 0 through 9. Here, I've also provided a default value, to remind the user to begin the phone number with a 9 to dial an outside line. The user can backspace over the default provided (using the << soft key provided by default as part of the <CiscoIPPhoneInput> tag) if he or she does not want to use the default. Other options that can be used for limiting the input keys are Numeric, Uppercase, Lowercase, Password, and Equation. There is no mechanism for providing a hidden field with hidden data or defaults. When I press Submit (this soft key is provided by default), the phone builds a composite URL from the URL provided, the name/value pairs implied by <QueryStringParam>, and the information entered, and sends it to the identified server. In this example, if I finished entering the name Annie and the phone number 95035550987, the application would build the following URL:
http://myserver/thanks.xml?name=Annie&number=95035550987
|
Thanks.xml would then, in this example, compose the XML for the new directory entry, and add it to AddNew.xml. Of course, you would probably want to have personal phone numbers stored in a database and customized for each phone user -- but an even better method might be to use CallManager's Custom Directories option. Still, it's neat to be able to embed a "call this number" function into an XML-based application. Refresh headers and application servers
One of the few additional HTTP capabilities supported by 7940/7960 phones is the HTTP refresh header, which can be used to either refresh the file currently displayed by the browser, or to load another file after a specified period of time has elapsed. I added this support by replacing the XML file with a JavaServer Page (JSP), and adding the setHeader response tag as shown in Listing 6:
Listing 6. Refresh.jsp
<?xml version="1.0"?>
<% response.setContentType("text/xml"); %>
<%response.setHeader("Refresh","3; url=http://myserver/webapp/examples/Refresh2.jsp"); %>
<CiscoIPPhoneText>
<Title>Hello!</Title>
<Text>Hello from the WebSphere Application Server!
Refresh in 3 seconds.</Text>
</CiscoIPPhoneText>
|
Since this is now a JSP, I needed an application server to serve it. Since I was already running WebSphere Application Server 3.5.4 on myserver, that was my application server of choice. I added the JSP by first placing it into the directory of an existing Examples application -- that is, by copying it into:
/usr/WebSphere/AppServer/hosts/default_host/examples/
|
I also added the following to the MIME table parameters for WebSphere Application Server's default_host:
While the details will vary if you are using a different application server, you'll still need to perform the same steps: making the JSP available to the application server, and ensuring that the application server will recognize XML as a valid MIME type. Figure 9 shows what appeared on the screen when I executed the application. Three seconds later, as promised, the application executed the refresh (shown below in Figure 11).
Figure 9. Refresh.jsp
Picture, picture on my phone
The refresh header in the example above executes Refresh2.jsp, which displays an IBM logo.
Figure 10. Logo prior to conversion
Pictures on the Cisco phones must be converted to a stream of hexadecimal digits that describe the picture in a proprietary packed-pixel format. Pictures are limited to 133 by 64 pixels; larger pictures do not display. Luckily, Cisco provides both a Photoshop plug-in and a stand-alone DOS-based program to convert GIFs to the phone's format. I took the IBM logo shown in Figure 10 and used the DOS-based program to convert it:
Gif2cip <input-file> <output-file>
|
This creates a dummy XML output file, containing the <CiscoIPPhoneImage> portion of the file in Listing 7 below. A 2-bit grayscale is used for each pixel; I found that blue converted to a very pale gray, and had to change each 6 in the <Data> tag to an F in order to get a logo dark enough to photograph. I then added the refresh header, which in this case points to an additional logo file, which in turn points back to our original Refresh.jsp.
Listing 7. Refresh2.jsp
<?xml version="1.0"?>
<% response.setContentType("text/xml"); %>
<%response.setHeader("Refresh","3; url=http://myserver/webapp/examples/ebizlogo.jsp"); %>
<CiscoIPPhoneImage>
<Title>IBM Logo</Title>
<Prompt/>
<LocationX>-1</LocationX>
<LocationY>-1</LocationY>
<Width>53</Width>
<Height>23</Height>
<Depth>2</Depth>
<Data>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
001000001F00FF0F40FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0100
01000001401F00F4FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01FF01
1FF001F401F4FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1FF01F0040
1F000F40FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01FF0100F401
0104F4FFFFFFFFFFFFFFFFFFFFFFFFFFFF41FFFF1FF01FF0011F1040
40FFF1F4FFFFFFFFFFFFFFFFFFFFFF1144FF1F00100000F0000F0F40
4F04FFFFFFFFFFFFFFFFFFFFFFFF14FFFF01000100F00FF0F000F40F
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F</Data>
</CiscoIPPhoneImage>
|
Note that no spaces or newlines are allowed in the <Data> section. Figure 11 shows how it looked on the phone:
Figure 11. Refresh2.jsp
Note that the phone pane is cleared before the picture is displayed, so to show text at the same time as the picture, you must incorporate the text into the picture you're displaying. The Cisco SDK provides a JavaScript ASP example -- the Stock Chart service -- that uses the toolkit to display a graphic of the CSCO stock price, converted at execution time. It uses calls to the CipImage library provided with the SDK to do the conversion.
Conclusion
At this point, you've seen the main functions available for use in building an interface from the Cisco 7940/7960 phones to enterprise applications. I can build menus, display text and images, and accept user input. This is a somewhat more limited version of the functionality provided by the average WAP phone of a year or two ago. I've shown that, using the XML browser provided by the phone, I can interact with my HTTP-based Web server and my Java-based application server. This limited interface can, with some thought and ingenuity, be used to provide enterprise integration or parsing of Internet-based functionality. The examples shown in this article provide a simple starting point to options limited only by your imagination.
Acknowledgements and disclaimer
I would like to thank Dennis Stoller of IBM Global Services and Jay Allen of the Linux for Services Providers Laboratory for letting me use their Cisco CallManager and phone infrastructures. I'd also like to thank Dan Haskell and Robert MacFarlan for taking screen shots.
This work represents the view of the author, and does not necessarily represent the view of IBM. It is based on laboratory tests undertaken in a laboratory environment. Results in particular customer installations may vary based on a number of factors, including workload and configuration in each particular installation.
Resources
About the author  | | |
Veronika Megler is a Consulting IT Architect in IBM's eServer pSeries Solutions Development organization. She currently works with wireless solutions, and has worked in operations, application development, systems programming, systems management disciplines, and IT management consulting. She enjoys architecting solutions to solve real business problems, then proving they work in practice. You can reach her at vmegler@us.ibm.com.
|
Rate this page
| 
