Individual Project Report
Name : Nicholas Towers (
[email protected]) Course : MEng Computing IV Supervisor : Peter Cornwell (
[email protected]) Second Marker : Stuart Cox (
[email protected])
Title :
Implementation of a Generalised API for Application Control by Telephony Devices June 2000
1
Abstract Increasing use of data communications over telephony services is leading to widespread application software development. At the same time, the proliferation of messaging technologies such as SMS
1 has consolidated the major market
share of telephony-based communications, making a wholesale migration to personal internet services unlikely in the near future. Support by application pro-
2 tones, voice control, SMS and WAP3
grams of multiple services such as DTMF
therefore becomes attractive to ensure the widest possible customer access.
4
This report describes the design, implementation and evaluation of an API
for application control by generic telephony devices. Several speci c solutions already exist for communication between handsets and systems such as telephone banking and customer service centres. However, commercial opportunities for these applications are growing rapidly with the widespread uptake of mobile telephony, in addition to the large installed base of xed line telephones. No architecture exists to permit re-use of client interface software.
The API developed in this project addresses these problems by oering an interface to telephony (DTMF, voice, SMS, WAP) services which communicates with application programs through a service daemon. Access to the applications
5
via remote control over the Internet (WWW , telnet, email) is also provided. The applications developed during the project to evaluate the API demonstrate eective communication with users employing each of these services. Further work undertaken has led to the implementation of a library interface for programmers, enabling eective commercial use of the API.
1 2 3 4 5
Short Messaging Service Dual Tone Multi Frequency Wireless Application Protocol Application Program Interface World Wide Web 2
Acknowledgements This project has taken a considerable amount of time and resources and I would like to acknowledge the help of all of those who have made the project possible. In particular I would like to thank my supervisor Peter Cornwell for his time, patience and guidance, and also for allowing the idea to be pursued originally. I would also like to thank Justin Cormack for his help, and my second marker Stuart Cox for his time and advice.
Further to these people I would like to thank the members of the Computer Support Group for their technical help in setting up various machines and telephone lines. Also, I would like to thank all of the many thousands of people who have worked on all of the Open Source projects without whose efforts this project would not have been possible. A list of these projects is given in Appendix A.
3
Contents
Abstract Acknowledgements Contents 1 Introduction
2 3 4 6
1.1
Aims & Objectives of the Project . . . . . . . . . . . . . . . . . .
6
1.2
Overview of the Project Progress . . . . . . . . . . . . . . . . . .
7
1.3
Overview of this Report . . . . . . . . . . . . . . . . . . . . . . .
8
2 Background Research
10
2.1
Motivation & Currently Available Products
2.2
Design of the API
2.3
. . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.1
Devices to be used with the API
. . . . . . . . . . . . . .
12
2.2.2
Analysis of the Device Capabilities . . . . . . . . . . . . .
17
2.2.3
Analysis of Likely Application Needs . . . . . . . . . . . .
19
2.2.4
Internal API Design
22
. . . . . . . . . . . . . . . . . . . . .
Extensions to the Basic Design
. . . . . . . . . . . . . . . . . . .
3 Implementation
23
25
3.1
Core API Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Service Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1
Managing Connection State Information . . . . . . . . . .
29
3.2.2
Select() Communication Model . . . . . . . . . . . . . . .
31
3.2.3
Use of the Linux pthread library
3.3
. . . . . . . . . . . . . .
31
. . . . . . . . . . . . . . . . . .
33
Cursor Application . . . . . . . . . . . . . . . . . . . . . .
33
Access Device Implementations . . . . . . . . . . . . . . . . . . .
34
3.4.1
Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.4.2
Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.4.3
WAP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.4.4
Email
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.4.5
DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.4.6
SMS Message . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.4.7
Voice Control . . . . . . . . . . . . . . . . . . . . . . . . .
42
Using Applications with the API 3.3.1
3.4
3.5
API Dynamic Library
3.6
Conversion of Existing Applications 3.6.1
3.7
. . . . . . . . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . .
44
Magicpoint Presentation Package . . . . . . . . . . . . . .
45
Support for Multi-User Applications
4
. . . . . . . . . . . . . . . .
47
4 Evaluation
49
4.1
Quantitative Analysis of the Implementation
. . . . . . . . . . .
49
4.2
Qualitative Analysis of the Implementation
4.3
Comparison to Other Available Systems
. . . . . . . . . . . .
51
. . . . . . . . . . . . . .
54
5 Conclusions
57
5.1
Commercial Applications of the API . . . . . . . . . . . . . . . .
58
5.2
Possible Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Glossary References Appendix A : Software Used Appendix B : Example Code Use of the API Appendix C : Obtaining The API
61 62 64 65 74
List of Tables 1
Capabilities of Devices for use with the API . . . . . . . . . . . .
17
2
Evaluation of Features Implemented in the API Design . . . . . .
49
3
Evaluation of Features Implemented in the Service Daemon . . .
50
4
Evaluation of Access Device Methods Implemented . . . . . . . .
50
5
Evaluation of Sample Applications Implemented
50
. . . . . . . . .
List of Figures 1
Diagram of the Proposed API Architecture Design
2
Screen Capture of Daemon Status Information
3
Screen Capture of Telnet (TCP Socket) Access Method
. . . . .
35
4
Screen Capture of Web Access Method . . . . . . . . . . . . . . .
36
5
Diagram of the WAP implementation
. . . . . . . . . . . . . . .
37
6
Screen Capture of Email Access Method . . . . . . . . . . . . . .
38
7
Screen Capture of Magicpoint Application . . . . . . . . . . . . .
45
8
Screen Capture of Cursor Application in use with the API . . . .
65
5
. . . . . . . .
12
. . . . . . . . . .
30
1 Introduction This document is a report for the individual project Implementation of a Generalised API for Application Control by Telephony Devices.
The project is
an attempt to design and create an API (Application Program Interface) for applications so that they can be used by numerous dierent telephony services without speci c knowledge of the capabilities of these devices by the application. Examples of these services, or access devices, include DTMF (Dual Tone Multi Frequency) tones from telephones, a WAP (Wireless Application Protocol) interface to mobile telephones and SMS (Small Messaging Service). The main di culty with the creation of such an API is the fact that these access devices oer considerably variable levels of functionality to the user. The need for such an API is justi able. The use of xed and mobile telephones is a common part of everyday life for the majority of people in the Western world, and is considerably more common than the use of personal computers. The use of these devices for input and output from computer applications, although now common, is relatively basic, with little standardisation. It is likely that the usage of these devices will increase in the future, particularly with the introduction of commodity hardware capable of handling concurrent telephone calls. By creating a standard generic API applications can be converted once, and with this change work with a large number of disparate access devices. For the developer of a new application it gives a potentially greatly increased user base, whilst not creating too high an additional coding burden.
A new
application can also bene t from the advantage of non-recurring engineering allowing greater sophistication in the use of such an API. This project also explores the possibility that a user may wish to control an application from multiple locations regardless of the device that they have access to at that point in time - the fact that the user should not be limited to the case where they are physically in front of a computer hosting the software.
1.1 Aims & Objectives of the Project The aim of this project is to create an API for application control by telephony devices, and to produce a number of example applications and separate device implementations. In other words the goal of this project is to abstract the input and output interfaces of an application to the extent that new access devices can be added to a system without any changes being necessary for the application. Thus applications do not need to be rewritten to cope with each technological advance, and devices only need to be added into this system once to gain from immediate access to all available applications. A signi cant part of this project is to look at how the API can be implemented so as to be exible enough for use with many varied devices whilst being powerful enough to allow access to the functionality of the application. Some examples of these access devices are
6
as follows :
DTMF tones - Tones created by telephone key press, with audible response by text-to-speech synthesis
SMS messages - Short textual messages available from mobile telephones
Voice control - Spoken commands given by the user, with audible response
WAP connection - A browser connection to a mobile phone or PDA
A number of example applications will also need to be created in order to evaluate the implementation. An example application would be to move a cursor around a screen, or to control a character in a game, from these devices. Application output should be provided to the user appropriately dependent on the access device used. With this API in operation, a user should be able to access all of the features of an application by telephone, rather than by having to sit at a terminal and use a keyboard and mouse. The nature of the abstraction of the access methods should also allow for the implementation of access devices which are not telephony but network based, such as a web browser and an email message. Implementing these methods in addition to the telephony access methods will demonstrate the potential of this project and allow users more choice in the access of applications. It should be noted that the goal of this project is very much to prove this concept, rather than to produce an optimised solution which can undertake very high load from concurrently running applications. The API should however be able to support multiple applications, each with potentially multiple concurrent users, accessed from arbitrary access devices. It should also be able to sustain an acceptable interactive response for these users regardless of their access method. Some possible uses for this API are at public information points, where a simple input device is preferable; as a tool for system administration to operate and control a system remotely; and as a method for members of an audience to participate in a large project, or vote on an issue, where the cost of providing input devices for multiple users may be prohibitive. The aims of the project were originally set out in the project proposal[1] in November 1999.
1.2 Overview of the Project Progress A formal view to the progress of the project was taken and resulted in a systematic development of the required components. In order to meet the stated aims, the following steps were undertaken : 1. Initial Design - The project was split into four separate parts, which were designed independently:
7
(a) Design of the API - Consideration of issues such as the services required, the semantics of the needed operations and the language and systems to be used. (b) Design of a central service - In order to communicate with the access devices and the applications a central service is necessary. The main issues to be considered are how messages should be passed and how much state information should be held by this service. (c) Design of a number of access device methods - This included design of an interface for input and output between DTMF tones, a WAP browser, SMS messages, a telnet connection, email messages and a web browser. (d) Design of a number of sample applications using this API - This included an application to move a cursor around a grid, a presentation package and an application to navigate a 3D world. 2. Speci cation - The interfaces between the four areas were speci ed precisely, and the requirements for each of the four sections were elicited. 3. Implementation - These four areas were separately implemented, mostly in C, but using Perl where appropriate. Wherever possible existing systems were used to provide the basis of the functionality. 4. Testing - The implementation from each of the four parts were then tested as a single system 5. Evaluation - The system was evaluated through comparisons to existing systems were possible and through qualitative analysis of the commercial viability of the implementation. On completion of the project this report was produced to document the decisions made in the above steps and to comply with the required regulations for a project report in the Department of Computing at Imperial College[2].
1.3 Overview of this Report This report fully describes the project undertaken. However in order to control the length of the report, the reader is on occasion referred to a bibliographical reference if particular details are required in an area. The report is split into ve main sections : 1. Introduction - This gives an introduction to the project, its aims, an overview of the work undertaken in the project and an overview of this report. 2. Background Research - Analysis of current projects available in this area and an attempt to de ne what is the state of the art. It also contains
8
analysis of the design issues for implementation of a possible solution to the problems raised, and a discussion of the technologies behind each of the proposed access device methods. Further, possible extensions to the basic design requirements are proposed. 3. Implementation - Discussion of the implementation choices taken and the software that was developed. Detailed reports are given for the implementation of the API and the implementation of the daemon which manages connections from users along with a sample application which uses the API and analysis of each of the implemented device access methods. In addition an example is given for converting an existing application to use the API and the subsequent development of a dynamic-link library which allows more eective use of the API by third parties is discussed. 4. Evaluation - Evaluation of the success of the implementation in meeting the needs discovered in the background research is given in quantitative and qualitative terms. The system is compared to other available products. 5. Conclusions - Analysis of the successes and failures of the project, and discussion of the advances made. A discussion of the commercial viability of the implementation is also given. Possible extensions and further work that could be undertaken are then discussed. In addition to these main sections there is a glossary and bibliography of references at the end of the report, along with a number of appendices.
These
appendices contain :
Appendix A - A list of the software and hardware used in the project, including URL in order that the reader may investigate the packages and tools further.
Appendix B - A sample use of the produced library. A simple application which moves a cursor around a text grid is given in full to show an actual use of the telephony API library that was implemented.
This example
demonstrates how a developer could add this API to their own projects.
Appendix C - A reference point URL for the reader to obtain the nal version of the library produced, and also to download all of the deliverables associated with this project, including this report.
This document has been created in the LYX typesetting system which operates in the
LATEX environment.
9
2 Background Research The project came about in response to the need to allow access to information and control systems from remote or mobile locations using everyday equipment. However, enabling this on a case by case basis for an application is di cult, time consuming and does not enable future devices to be used without changing the application. This background examines the steps taken to design the API by looking at the various components of the system, and gives references for further reading on the technologies used.
This section tries to consider the
current state of the art in this area by looking at currently available products and tools. From this the shortcomings of these products can be analysed, giving a base for the production of a new generalised API. The rationale behind the project is that if a simple API can be developed as an interface between applications and these devices, then the task of adding each separate device is an operation which only needs to be undertaken once rather than on a per application basis.
The simpler and easier that the API
is to use from an application standpoint, the more likely it is that application developers will be prepared to support the API. Likewise another design goal is that the ability to add new devices is as simple as possible. Overall then the project splits into : 1. The theoretical design of the API architecture 2. Implementation of this design 3. Implementation of at least one device driver which interfaces with the API 4. Implementation of at least one example application which interfaces with the API However before looking at the actual design process, it is important to look at the motivation for the project in a little more depth, and to see which other projects or research in this area have been undertaken.
2.1 Motivation & Currently Available Products Analysis of available research papers and extensive searching on the Internet has failed to uncover any other projects attempting this kind of generalised API for telephony devices. However, the API can be looked at from two other points of view - from the device side (considering a particular device such as DTMF tones) or from the application side (considering a particular application which has been designed for control by telephony devices).
From these view
points a number of systems can be considered as providing at least some control functionality.
10
Although many gateways exist between various telephony devices and other systems, for example between SMS and email, these do not give application control, nor operate in real time. The most similar case to be considered is in the use of a DTMF telephone to control and navigate a user through a menu system. However, in this case the application has been speci cally created for this interface, and is dependent upon it.
There are a number of cases where
remote access has been used via the world wide web or by connecting to the machine using an application such as telnet, however these are also speci c to a particular method and do not scale to a general case. As these methods are simple to implement on top of a basic API though, and are very useful for testing and debugging purposes as well as for demonstrating the functionality of the project, they could be employed here as exemplar services. From the point of view of the application, it is common for the developer to create the application without the knowledge of the exact mouse or trackball that the user owns, just the idea that a pointer will be used.
However,
the situation in this project is a considerably broader approach where the aim is to minimise the knowledge necessary from the application developer about the access method, as this allows for a greater breadth of potential devices. A high proportion of applications are currently created tied to a keyboard / pointer interface due to the fact that this is available, rather than because it is necessary. It is almost automatic for any developer looking to create applications for the X Windows system to use the built in event model, which is based around KeyPress and ButtonPress events. In many applications, a simple cursor based movement su ces (eg. some games, reading a document, navigating a menu system etc.) whilst in others the user is simply looking at yes / no responses or checking status (eg. checking that a system is still alive, answering a questionnaire etc.). A major aspect of the design phase is to make a decision on the basis of whether the application itself can bene t from the knowledge of the type of access device that is being used at that point in time, or whether the API implementation should make this completely transparent.
The advantage of
providing the application with this information is that it may be able to give output tailored to the access device. However, with this increase in functionality is brought an increase in complexity for the design of the API and complexity in the use of the API by the application. It is possible that the use of this feature if present can be optional for the application. In this case the complexity would only be there for applications that wish to make use of features speci c to a particular access method. Thus the motivation for proceeding with this project is that a large number of users who do not have access to a computer at a moment in time or in a certain location could still be using their applications with the devices available to them.
Furthermore, if the API is designed successfully then adding this
functionality should be very simple for application developers.
11
2.2 Design of the API The API itself must be compatible with the major sets of access devices set out in the project proposal. Thus the capabilities to control applications are limited by the particular capabilities of these devices. In order to design the API itself, each of the possible device cases needs to be examined in order to determine how they could provide input and output to an application. After these have been considered, a base set of functionality can be established which can be used to consider various designs for the API itself. For reference whilst considering these access devices, and the design of the API itself, an overview of the proposed architecture for the system is given in Figure 1. Status Data
Telnet
APP 1
Application
Web
APP 2
Application
Web
APP 3
Application
Access Device
Telnet
Access Device
Access Device
Service Daemon
Web
Access Device
Figure 1: Diagram of the Proposed API Architecture Design
This Figure shows how a service daemon maps users who are connecting to the API from various access device methods to a set of applications. Also, status information can be obtained from the daemon by a telnet connection. The important point to realise is that the mapping should only be dependent upon the needs of the users, and not due to limitations in the design of the system. Also, note that the rst application has multiple users - the requirement for this facility is discussed in section 2.2.3.
2.2.1 Devices to be used with the API In the following device sections, host refers to the machine running the application and the API. For each device there is an analysis of the capabilities it contains and a view of the current systems available using this device.
Note
that the set of devices considered for inclusion was chosen on the grounds that the device is:
12
Readily available to many potential users - Although devices with a small user base may well be used with the API, the priority was to focus on an implementation that can be used by as many users as possible, whilst keeping the necessary amount of work manageable.
Capable of input and output - Devices incapable of input such as a pager, or only capable of output such as a speaker, are inappropriate targets for an API designed for users to control and receive feedback from an application.
Capable of a usable level of interactivity - The API is designed for real time usage and thus a system such as conventional postage is inappropriate due to the delay which is unacceptable to the user.
Capable of autonomous usage - The API is designed for embedded use without operator control. Without this the API would have it's scalability limited to the number of operators present, and this would considerably increase the costs of an actual implementation of the nal product.
Capable of initiating and terminating the connection - The user must be able to start the session by sending some form of request, the API should not have to poll users to see if they wish to send any requests to the system. This is due to the fact that a polling approach would scale very poorly - it is likely that for many applications the user may only wish to access the application very infrequently. e.g. A system administrator checking the status of a system. Likewise considerable load could be placed on the system if the user could not terminate sessions, and these had to timeout or were left open. Another consideration from this point is cost - network bandwidth and telephone calls are not free, and costs to the user should be minimised if the API is to become popular.
2.2.1.1 DTMF (Dual Tone Multi Frequency) Telephone
This device
is a standard POTS (Plain Old Telephone Service) telephone supporting tone generation by use of the numeric key pad.
The device has 12 distinct inputs
given by 12 unique tones (characters 0-9, # and *), no display and output is via real time audio. A continuous connection is established for communication, with negligible communication delay. Full speci cations of the DTMF decoding interface can be found in the blue book [3]. An example of this interface is a telephone banking service which requires the user to enter details such as bank sort code. Mobile telephones can also be used via this method, but note that the frequency range available is more limited due to the GSM speci cation[4]. In order to communicate with such a device a telephony card can be used in the host computer servicing the connection in order to interpret the tones generated by the user and to respond to the user with audible output through the telephone.
13
This output should take the form of a voice response, which may be generated via text-to-speech synthesis on the host computer. There are a number of systems in current use which take advantage of the DTMF tones.
An example is the telephone banking system run by Halifax
Bank[9] into which the user enters their account number, sort code and PIN code with the system responding with balance and transaction information. Note that in this case the responses are often pre-recorded rather than generated on demand.
It is also of note that the speci c software that exists for
some telephony cards to provide these services is not generalised to other access methods or even to other manufacturers telephony cards.
2.2.1.2 Voice Recognition
This uses the same international phone system
as with DTMF, but instead of inputting information via the numeric key pad, voice commands are given.
This requires voice recognition techniques on the
machine servicing the call, as well as the ability to interpret the incoming audio in some form of analog to digital conversion. The facility for this conversion is included with many telephony cards, but the actual interpretation of this data is not, and is left to the designer of the system. Note that it may be required for the system to cope with issues such as background noise, accented speech, mu ed sound and ambiguous responses. An example of a system in current use is that of the Odeon cinema group[10] which has a system for booking tickets by telephone. In this system the user states by voice the cinema they wish to visit, and the system is able to choose the most likely cinema from a known list. Thus the user can pro-actively choose the destination rather than having to choose from a set of supplied options. This is used as it gives a shorter response time to the user than having to select a cinema with a DTMF choice from a very long list. The advantage this holds is that it provides a solution to one of the main user complaints about automated telephony services - that the user is stuck in a pre-de ned set of choices which limit the interactivity available, and force the user to wait to access the function they desire. This is even though the majority of systems do allow the user to access a function directly if they know the commands. A feature of note from the Odeon system is that the system acts for con rmation of all information supplied by voice, in order to reduce errors. Although this increases the time of call for the user, the time is still far less than if the user did not have the option to choose cinema by voice command.
2.2.1.3 SMS (Short Messaging Service) Message
The vast majority of
modern mobile telephone systems allow the transfer of textual messages using the SMS system (also de ned in the GSM speci cation). These messages can be up to 160 characters in length, and can be sent and received by mobile telephones. There is no concept of a connection, each message is independent. No response time is guaranteed, however personal experience would give a common
14
response of about 1-5 seconds. From the host side either a system supporting SMS messages on a telephony interface or some form of SMS gateway needs be used. The approach taken by most network operators in the use of an SMS Centre (SMSC) which transmits the message out onto the network, and receives messages sent out by the networks subscribers. The various network operators then peer with each other at the SMSC level.
However, individuals are not
accepted as a peering point, and in order to create some form of SMS gateway to the host computer some form of encapsulation through an actual mobile telephone is needed. Research has not discovered any system in use in this country for controlling applications via SMS messages. However, there are many systems such as the one used by Orange[11] for delivering news about Formula 1 developments to their users. The SMS system is also used by the network operators of mobile phones for the delivery of microcode updates to mobile telephones - which is a use of the system for sending commands, but not at a user level.
2.2.1.4 WAP (Wireless Application Protocol)
WAP oers a connection-
less or connection oriented protocol stack. The page based approach is similar to the web paradigm.
The process used is that a request for a page is given
from the wireless device (eg. WAP capable mobile telephone) to a WAP gateway, usually tunnelled through a PPP connection to a modem. This machine then asks the web server given in the URL in the request for the appropriate WML page, and binary encodes the page on arrival. This encoded data is then sent back to the device, which decodes the information to display upon a screen of some kind. A full speci cation can be obtained from the WAP Forum[5]. A maximum page size of 1500 bytes is de ned, and the assumption is made that pages are designed for use on devices with small displays such as mobile telephones. Thus the host machine needs to oer a web server capable of oering the WML pages which in this case will need to be generated on demand, through the use of the Common Gateway Interface or similar. WMLScript can also be used to oer additional functionality. The user may then respond by choosing a hyperlink or by entering textual data into a form. An excellent white paper on this emerging technology is available from AU-Systems[6]. Mobile telephones with WAP browsers are becoming increasingly widely available. Most WAP based services currently in use are cut-down versions of web sites containing up to the minute news, sport and travel information for the user. The WAP paradigm is being seen as exploitable with the use of highly personalised and localised data, with location being given by the triangulation of the position of the mobile telephone between base station points. However, this has a number of associated privacy issues. Although many WAP systems in use such as the one provided by Orange multimedia[12] allow the user to enter data (e.g. to pick up travel information on a particular road) there are no gateways currently available to map this information onto an application in a
15
general way. In other words each use of an application such as travel information is currently written on a case by case basis.
2.2.1.5 World Wide Web
A web based interface allows output to be pre-
sented as a page in a web browser. The page is formatted in HTML, possibly with the extension of Java / Javascript. The use of HTML forms and hyperlinks to other pages allows input to be received from the user. Apart from the dierences between WML and HTML and the fact that no assumption on display size is made with HTML, this method is analogous with the previous WAP service. The host needs to run a web server as speci ed in RFC[7] 2068, which is capable of generating HTML pages in real time through the use of CGI techniques. As an established medium of document delivery and application development there are a vast array of systems with web interfaces in use. The majority interface with applications by means of a CGI program running scripting languages such as Perl, Java Servlets or Active Server Pages. An example would be a bookshop such as Amazon[13] which allows the user to order books over the web - the web front end connects through a CGI interface to a transactional database. The CGI interface is well de ned and used - although if a user wishes to control an application which has already been created or designed for the X Windows system or for a text terminal a considerable amount of programming is needed at the CGI level on a per application basis.
2.2.1.6 Email
Electronic mail could also be used as an interface to the API.
This is analogous to accessing the application via an SMS message, except that there is no limit of 160 characters per message built into the system. As with SMS there is no guaranteed delivery time, but in most cases the timing is of the order of a few seconds. The host needs to run a mail server as speci ed in RFCs 821 and 822, and an email address is necessary for receiving messages.
The
arrival of a message to the system will need to cause some program or script to operate and communicate with the API. This script will then be able to send a message back to the recipient. A number of systems exist to take commands via email, with response given in a return email.
An example of this is Ftpmail[14] which wraps an FTP
session inside a set of email messages.
However, there is no current map of
this technique onto a generic input and output mechanism for applications, the mapping has to be made speci cally, and a service to receive email messages has to be ran on a per application basis. Thus if a number of these service were to be ran concurrently, each would require separate lters and analysis of the messages.
An example of the crossover between email and SMS technologies
is that a number of gateways exist such as Genie[15].
These can be used to
send an email using an SMS message, or vice versa. The fact that these sites have proven popular is a demonstration of the fact that users wish to access computer and telephony based services regardless of the device which they have
16
at that time. One of the common uses of Genie is for users to send themselves email reminders through the SMS function of their telephone. This saves the user from having to carry a diary around with them, and eases the transition of the data into other applications.
2.2.1.7 TCP Socket
By using a TCP socket connection to the host, tex-
tual information can ow in both directions at any time, as this gives a full bidirectional connection. There is no limit on length in this access method. In order to transmit a message a new line command is needed. The host will need to oer a TCP socket for incoming connections to attach to on an unreserved port, as per RFC 793. The telnet application (or the more secure derivative ssh) is widely used for remote access to a machine. By running the same terminal as with a local login a user can seamlessly use the machine remotely. It is also possible to tunnel X Windows connections over this link. However, in order to gain mouse control remotely the user must run some kind of X Windows server on the local machine - the actual application itself cannot necessarily be controlled from the telnet client. And of course the user requires access to a computer with a telnet client. Thus in many ways the aim of this project is to extend the ability of having access to an application from a remote telnet session to the ability to access the application via each of the above devices, and to add access via a tenet client to applications which rely upon pointer input. This would enable control where a TCP socket connection is feasible, but the display cannot be exported.
2.2.2 Analysis of the Device Capabilities From the various capabilities of the devices, a set of restrictions and requirements for use can be derived. A table of the capabilities is given in Table 1 in order to compare the available functionality on a per-device basis. Access
Input
Input
Output
Output
Connection
Reply
Device
Values
Length
Values
Length
Continuous
Delay
DTMF
0-9,#,*
1
various
unlimited
Yes
= 0) { cellmove(lastrow, lastcol); } cellmove(rw, col); lastrow = rw; lastcol= col; } cellmove(rw, col); cellmove(rw, col); sprintf(msg, "Position (%d,%d)", rw, col); 69
werase(msgwin); waddstr(msgwin, msg); wrefresh(msgwin); wrefresh(boardwin); A do-forever loop is used which sets up the windows with the cursor in position. Two buers are cleared to store the messages that go to and are received from the telephony API.
if (help_msg) { if (tele_api_clear_mem(msg, MSG_LENGTH) < 0) exit(1); sprintf(msg, "Use the cursor keys to move around the screen, or # to quit. The application will respond with your position."); help_msg=0; } if (loop!=0) { if (tele_api_output(msg) < 0) exit(1); } In every iteration of the loop apart from the rst tele_api_output() is called with a message for the user. This message is either the position of the cursor, or a help message if this was requested.
free(msg); if (loop==0) loop++; if (tele_api_input(buf) < 0) exit(1); The application then waits for input from the user of the telephony API by virtue of a call to tele_api_input(). Once this is received the application can act upon this input.
c=buf[0]; free(buf); switch (c) { case 'k': case '8': case 8: case KEY_UP: ny = rw+BDEPTH-1; nx = col; break; case 'j': case '2': case 2: case KEY_DOWN: ny = rw+1; nx = col; 70
break; case 'h': case '4': case 4: case KEY_LEFT: ny = rw; nx = col+BWIDTH-1; break; case 'l': case '6': case 6: case KEY_RIGHT: ny = rw; nx = col+1; break; case 'y': case '7': case 7: case KEY_A1: ny = rw+BDEPTH-1; nx = col+BWIDTH-1; break; case 'b': case '1': case 1: case KEY_C1: ny = rw+1; nx = col+BWIDTH-1; break; case 'u': case '9': case 9: case KEY_A3: ny = rw+BDEPTH-1; nx = col+1; break; case 'n': case '3': case 3: case KEY_C3: ny = rw+1; nx = col+1; break; case '*': help_msg=1; break; case 'q': case '#': goto getout; break; default: break; } // switch A simple case statement is used to act on the input of the user. Note that if the telephony API standard calls for a help message (*) or to quit (#) are given by the user then they are adhered to by the application.
col = nx % BWIDTH; rw = ny % BDEPTH; } //for getout: } static void dosquares (void) { int i, j; 71
mvaddstr(0, 20, "CURSOR MOVE -- a telephony API demo"); The dosquares() function follows a simple set of ncurses calls to draw the grid around which the cursor can move.
move(BOARDY,BOARDX); waddch(boardwin, ACS_ULCORNER); for (j = 0; j < 7; j++) { waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_TTEE); } waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_URCORNER); for (i = 1; i < BDEPTH; i++) { move(BOARDY + i * 2 - 1, BOARDX); waddch(boardwin, ACS_VLINE); for (j = 0; j < BWIDTH; j++) { waddch(boardwin, ' '); waddch(boardwin, ' '); waddch(boardwin, ' '); waddch(boardwin, ACS_VLINE); } move(BOARDY + i * 2, BOARDX); waddch(boardwin, ACS_LTEE); for (j = 0; j < BWIDTH - 1; j++) { waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_PLUS); } waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_RTEE); } move(BOARDY + i * 2 - 1, BOARDX); 72
waddch(boardwin, ACS_VLINE); for (j = 0; j < BWIDTH; j++) { waddch(boardwin, ' '); waddch(boardwin, ' '); waddch(boardwin, ' '); waddch(boardwin, ACS_VLINE); } move(BOARDY + i * 2, BOARDX); waddch(boardwin, ACS_LLCORNER); for (j = 0; j < BWIDTH - 1; j++) { waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_BTEE); } waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_HLINE); waddch(boardwin, ACS_LRCORNER); } /* cursor.c ends here */
73
Appendix C : Obtaining The API The deliverables produced during the project are available for download. They available products can be found at :
http://www.doc.ic.ac.uk/~ncet/project/ At this location the following items are available for download :
The source code of the implementation of the API as a library (C)
The source code of the service daemon implementation (C)
The source code of the implementations for the device access methods (C and Perl)
The source code of the cursor application (C)
The source code of the magicpoint application (C)
The original project proposal (html and postscript formats)
The nal version of this report (postscript format)
The slides for the project presentation (magicpoint and postscript formats)
74