WTA - Wireless Telephony Application

As mentioned in the previous section, WTA is part of WAE, the Wireless Application Environment. WT A is designed primarily for network operators or carriers and equipment vendors. It hands network operators the opportunity to offer device independent services and it enables equipment vendors to create multi-functional devices, without having to bother about specific functions and user interfaces. This section first describes the WTA deSign, followed by its interfaces and it ends with an example of a possible WTA service.

5.3.1 WT A specification

The WTA architecture consists of three elements, particularly the WTA user-agent, the WAP Gateway, and the WTA server. The WTA user-agent is the client side WTA

application, i.e. the client in the user's mobile terminal. The WAP Gateway is the standard Gateway as shown in Figure 5-1, but with the added functionality of forwarding WT A requests from the WTA user-agent to the WTA server and vice versa. The communication path for WT A services is thus separated from the other WAE browsing services, as shown in Figure 5-3.

This separation provides the network operators with a way of limiting possible security risks of the WTA services. Network security and reliability are of course a major concern since WT A gives its service provider access to telephony functions in the mobile terminal.

An elaborate security scheme is mandatory for WTA implementations.

The WTA server can be thought of as a web server delivering content to the client. The user-agent can reference the WTA server by use of URLs, just like a standard web server. By referencing applications on a WTA server, e.g. CGI or ASP scripts, it is possible to create complex services, that interact with both the mobile network and external sources (e.g. databases, voice mail systems, 1 MORE servers).

621128 P.P.S. Giesberts

1MORE

Figure 5-3 WTA Architecture

In contrast to normal web operation, the WT A user-agent can both execute content that is stored persistently in the mobile client's repository and content that is retrieved from the WTA server. It can also react to incoming events from the mobile network (e.g. an incoming call). It supports push technology, where the WTA server is the only server that is allowed to push information to the user-agent.

The repository is a storage module within the mobile telephone that eliminates the need for network access when executing frequently used WTA services. It also addresses the issues that arise when trying to handle time-critical events during operation. More information on the WTA architecture, the repository and the WT A security requirements can be found in Appendix E.

The WTA framework allows real-time processing of network events. Within the

framework, the client, i.e. the user-agent, and the server co-ordinate the set of rules that govern event handling via an event table. WT A servers can adjust the client's rules by pushing or updating a client's event table. For communication between the user-agent and the server, WTA utilises one or more Wireless Session Protocol (WSP) sessions over a dedicated WTA port. The WTA user-agent is completely event-driven.

Actual control over the WT A invoked network functions does not lie with the WT A server but inside the mobile network, the mobile switching system (e.g. in case of a mUltiparty conference), and in the mobile terminal itself (e.g. phonebook access). The WTA server is a content delivery system and it can be an event generator for systems that are outside the mobile network. E.g. a voicemail system may rely on the WT A server to send an event to a terminal to notify its owner that a message is available.

5.3.2 WT AI specification

WT A exposes its services to content providers as a set of libraries and interfaces. The Wireless Telephony Application Interface (WTAI) features are partitioned into a collection of WT AI function libraries. The type of function and its availability determines where the different functions are specified. The WT AI function libraries are accessible from WMLScript using the scripting function libraries. Some WT AI functions are also accessible from WML using URIs.

These functions may initiate an interaction between the mobile and the network. The function then typically terminates independently from the started network procedure. So any result delivered by the function call will not reflect the outcome of this procedure, which itself may result in events. For example a 'user busy' condition is not reported by the return value of the 'set-up call' function but is delivered by the 'call cleared' event.

WT A functionality is divided across several libraries according to its sensitivity and applicability. WTA defines three classes of WTA services: network common, network specific and public WTAI. Network Common WTAI contains the most common features that are available in all networks. They are only accessible from the WT A user-agent.

Examples of functions are call set-up and 'answer incoming call'. Network Specific WTAI are features that are only available in certain types of networks. Operator-specific features may also reside in this set. Public WT AI consists of simple features that are

P.P.S. Giesberts 63/128

leS/ES 750 1MORE November 2000

available to third party applications that are executed using the standard less restricted WAE user-agent. A complete overview of public and network common libraries can be found in Appendix E.

5.3.3 Example of a WT A service

The following example is taken from WAP 169, Wireless Application Protocol - Wireless Telephony Application Specification, a publication of the WAP Forum (July 2000). It shows a possible implementation of an extended user interface for the handling of incoming calls based on WT A functionality. It is included here to clarify the WT A framework and its application.

The service is automatically started when an incoming call is detected in the client. The needed application, which is called a channel in WT A terminology, is stored permanently in the terminal's repository. A menu with five options is presented to the user. For instance, he can accept the call immediately and talk to the other party, or he can put the other party on hold for some time and accept the call later. He can also reject the call completely in which case the other party gets a busy signal. The user can also choose to forward or redirect the call to his voicemail box or to another telephone, in this case his office.

Figure 5-4 shows what happens when an incoming call occurs:

1 The mobile network receives an incoming call and sends a "Call indication" to the mobile subscriber.

2 In the client, the incoming call WTA event (wtaev-cc/ic) is generated. The repository is consulted in order to find a dedicated channel. The channel provides the URL to the "Incoming Call Selection" service stored in the repository.

3 The user-agent requests the content from the repository.

4 The repository returns the requested content.

5 The content is loaded into a clean context and starts executing. The service presents a list of options to the user, from which he/she can choose how to proceed with the call in progress. In this example he/she elects to answer the call. The WTAI function 'WT AVoiceCall.accept' is invoked.

64/128

Figure 5-4 WT A example incoming call selection

P.P.S. Giesberts

1MORE November 2000

leS/ES 750

6 A 'Connect' request is sent to the mobile network (the invoked WT AI function communicates with the mobile network).

7 A 'Connect Acknowledgement' is generated in the mobile network. A result code indicating the outcome of the call is generated internally in the phone.

8 A speech path between the mobile network and the client is established.

Note that neither the WAP Gateway nor the WTA server is used during any of the steps above, as the application is stored in the terminal's repository. This application was loaded from the WTA server to the repository during a previous event and has been available ever since.