MXPA99008863A - Device and method of radiocommunications with api between the program of user application and the program and method of telefo - Google Patents

Abstract

A radio communication device has a memory that has stored therein a user application program (16), a telephony program (18) and an application program interface (API) 30 therebetween. Several aspects of the API are written (30). In one aspect, the API (30) has. an order to establish a call and the telephony program (18) accepts it, as an argument of the order happens to establish the call, a set that identifies several terminal objects (54-58), thus allowing the establishment of a call for multiple objects to finish. In another aspect, the event groups are described and an API order (30) defines, an event class of one of the groups together with an ID that defines an event within the class of events. In a further aspect, a telephony program (18) is called to create a call object (50). The call object (50) is created without considering, if the radio service has been established for the radio communication device

Description

DEVICE AND RADIOCOMMUNICATION METHOD WITH API BETWEEN THE USER APPLICATION PROGRAM AND THE PROGRAM AND TELEPHONE METHOD FIELD OF THE INVENTION This invention relates to the radio communication device having a user application program (commonly referred to as an applet or application) and a telephony program (for example, an instance of a telephony class). and an application programming intee (API) between the user application program and the telephony program. The invention relates to aspects of the API and refers to a method invoked through the API, for example a method for establishing a dual-mode call. BACKGROUND OF THE INVENTION Object oriented object languages such as Java (TM) are increasingly popular in more and more devices because of the portability of programs across platforms, devices and operating systems.

This means that a program developed for one device is used more easily in another device with different characteristics, for example different operating systems or different microprocessors. This popularity of targeted object programs extends to devices that are significantly smaller in terms of memory size and processing power than traditional personal computers and other platforms, in which such languages have been widely used. Problems have arisen when trying to use object-oriented languages such as Java (TM) on very small platforms for a number of reasons. An example of a problem is the need to support a complete set of object classes, where an object is a built-in computer program that interacts with other programs in a defined manner and where a class is a generic template for a set of objects with similar characteristics. One problem is that in order to maintain the portability of programs across different platforms, the uniformity in the classes that any given application expects to be able to invoke needs to be present. For example, pJava (TM) has a very large set of class libraries and efforts are in place to define a smaller language to be called "" -eJava "(TM) using only a subset of the complete set of Class libraries An example of a class is a telephony class that is invoked through a Java (TM) Telephony API (JTAPI). An instance of such class could be named a "JTAPI implementation". JTAPI is a portable application programming intee object oriented for computer-telephony applications based on JAVA (TM), described in the following universal resource locator on the world wide web: www.javasoft.com/products/JTAPl/index.html. The JAVA (TM) Telephony API supports both the telephony application domain of the first part and the third part. The API is designed to make simple programming applications easy while providing those features necessary for advanced telephony applications. JTAPI is a set of APIs. There is a "core" API that provides a basic call model and rudimentary telephony features, such as placing phone calls and answering phone calls. _ The core API is surrounded by standard extension APIs that provide functionality for specific telephony domains such as call centers and continuous access to media. The written applications that use JTAPI are transportable through various computer platforms and telephone systems. Version 1.2 of JTAPI was released to the public in December 1997. An example of using JTAPI is a network configuration where the JTAPI application or JAVA (TM) applet works at a remote station, such as a networked computer with only one screen, keyboard, processor and some memory. This computer accesses network resources, making use of a centralized server that manages telephony resources. JTAPI communicates with this server through a remote communication mechanism, such as the invocation of the Java Remote Method (RMI) or a telephony protocol. The JAVA (TM) telephony API is composed of a set of JAVA (TM) language packets. Each package provides a piece of functionality for a certain aspect of computer-telephony applications. Telephony server implementations choose the packages they support, depending on the capabilities of the platform hardware they cover. Applications can consult the packages supported by the implementation they currently use. In addition, the developers of the application can take care of themselves only of the supported packages that the applications need to carry out the task. For example, a call pack allows applet designers to add telephone capabilities to a web page, while a number of standard extension packets extend the JTAPI core packet. These extension packages bring additional telephony functionality to the API, such as: full control, call center, media, telephone, private data and capacity packages. It would be desirable to use a standard telephony API such as JTAPI as a telephony API for a radiotelephone or other radio communication device. A number of problems are found in the way to use JTAPI as a telephony API for a wireless communication device and in particular as a telephony API for a Global System for Mobile Radiotelephone (GSM). In general, JTAPI still suffers from the burden of having over 63 event classes with a total class file size of approximately 130 k bytes. This represents a substantial memory location for a relatively minor element of a total program for a radiotelephone. There is a need to reduce the memory requirement for programs that are compatible with JTAPI. In the context of a GSM communication device, there are GSM functions that can not be easily accessed using existing JTAPI method and syntax identifications. In addition, there is a need to support a dual mode call (which is a term used in GSM for a fax or voice call or a data or voice call) and the concept of a dual mode call is unknown in wired telephony and in JTAPI. Simply adding to JTAPI or reducing JTAPI does not provide satisfactory solutions, because adding to JTAPI increases the need to find classes of events and reduce JTAPI eliminates the benefit of a standard API that allows the transportability of applications through platforms. According to the above, there is a need for a telephony API for a radio device and associated classes that occupy a minimum of memory and support devices that are unique for radiotelephony. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows an example of a radiotelephone device, according to a first embodiment of the invention. Figure 2 shows an example of a radiotelephone device, according to a second embodiment of the invention. Figure 3 is a software architecture diagram illustrating the software structure or any of the radiotelephones of Figure 1 and Figure 2. Figure 4 is a flow chart of the program illustrating additional details of the JTAPI implementation of Figure 3. Figures 5 and 6 are flowcharts that illustrate details of the implementation of the JTAPI method in Figure 3. Figures 7-13 refer to Appendix 1 that describes JTAPI. DETAILED DESCRIPTION OF THE DRAWINGS Referring to Figure 1, a radiotelephone is illustrated in terms of different layers, with hardware in the lowest layer and application software in the highest layer. The radiotelephone comprises a first microprocessor 10 (microprocessor A), a second microprocessor 11 (microprocessor B) and certain hardware RF 13. The microprocessors A and B are connected together. The microprocessor B is connected to the RF hardware 13. The RF hardware 13 includes at least one receiver and one transmitter. The RF hardware also has speech communication elements 23 that preferably include a speech encoder, by way of example and data communication elements 24 that preferably include a data modem or fax modem, by way of example. The microprocessor has an operating system (OS) 14 such as OS 9000 supplied by Microware Systems Corporation of Des Moines, Iowa. Above the operating system, a virtual machine 15 is displayed, such as a commercially available JAVA (TM) virtual machine. An application program 16 and various other JAVA (TM) classes 17 operate in the virtual machine 15. One of the classes 17 is a JTAPI implementation 18. The microprocessor 11 has a transceiver software 20 which executes such functions as a control calls, structuring and generally manipulation of the byte level such as block coding. The transceiver software 20 communicates through a module interface of the common service provider (CSPMI) 22 with the operating system 14. As an alternative to the installation of Figure 1, the microprocessors A and B can actually be integrated into a unique integrated circuit 25, as shown in dashed line contour in Figure 2. In this embodiment, the microprocessor 10, the hardware 13, the operating system 14, the virtual machine 15 and the various software elements 16-18 are the Same as the embodiment of Figure 1. Instead of the microprocessor B, there is a digital signal processor (DSP) integrated with the microprocessor 10 in the single integrated circuit 25. The DSP 27 has DSP code 28 that executes the structuring and other manipulation of the byte level such as block coding, while other software functions of the transceiver such as call control, are executed by the software code of the transceiver 29 operating in the microprocessor 10 using the operating system 14. A suitable integrated circuit 25 is the integrated microprocessor M-core (TM) and DSP available from Motorola Inc, of Schaumb'urg, Illinois. In Figure 3, application 16 (referred to as a "telephone applet") is shown and the implementation of JTAPI method 18 is shown. A JTAPI 30 interface is shown interconnecting between the telephone applet 16 and the JTAPI 18 implementation. implementation of the JTAPI method 18 controls and receives the input of a radio transceiver such as a GSM transceiver 30 through the CSPMI 22. The GSM transceiver 30 comprises the second microprocessor 11, the RF hardware 13 and the transceiver software 20 (all shown in FIG. Figure 1) . JTAPI 30 is substantially as described in the JTAPI specification, version 1.2 that defines the syntax or operation of high-level objects, such as "Provider" and is set out in Appendix A. In addition, they are supported Certain specific operations for GSM, whereby the following specific semantics are now defined. The domain of the JTAPI Provider is simply the mobile station (MS). The only addresses in the Provider's domain are those in the MS, for example, a single address in the domain for a single online phone. Provider getAddresses () returns a set of addresses for the MS, typically with only 1 entry. If the MS supports multiple lines and telephone numbers, the omission or main address is the first entry. Provider getAddress () accepts only the number or numbers assigned to the MS. By default, the main address is returned, that is, getAddresses () [0]. Provider getTerminals () returns a set of Terminals supported by the MS. A separate terminal is defined for each type of call carrier (see below). Provider getTerminals () takes a string specifying the name of the terminal. By omission, the Voice Terminal is returned. All implementations must support VOICE, DATA and FAX as names for the respective terminals (see below). Provider createCall () will create a call even if the provider is OUT_OF_SERVICE since it has not been interrupted. The call can not be placed successfully until the Provider finds IN_SERVICE. This feature is a change to the preconditions of JTAPI 1.2 createCall () and is described below in more detail with reference to Figures 5 and 6. Cali. connect () parses the destination address string for common SS codes and address indications. If the destination number string goes to Cali. connect (s) starts with a character '' + ", the type of number (TON) is set to INTERNATIONAL; otherwise, the TON is UNKNOWN. If the string contains only numeric digits, the numbering plan identifier (NPI) is ISDN, otherwise it is UNKNOWN. TerminalConnect ion. j oin () and TerminalConnection. leave () are used to change call modes in a dual mode call (voice and data or voice and fax). There is always exactly one TerminalConnection that is active in a call; invoking join () in another TerminalConnection causes a change in the calling mode and calling leave () in the Active TerminalConnection, automatically activates the alternate. Applications can interact with the information content of the call using the API defined for MediaTerminalConnect ion. If a TerminalConnection comes back from Connection. getTerminalConnect ions (), implements MediaTerminalConnect ion, the application can use the following methods: MediaTerminalConnection. getMediaAvailabilit (), which is implemented as defined in JTAPI 1.2; MediaTerminalConnection. getMediaSt ate (), which is implemented as defined in JTAPI 1.2; MediaTerminalConnect ion. generateDtmf (), which is used to generate DTMF tones in the call. All other methods in MediaTerminalConnection are optional. The Provider does not necessarily disconnect any active calls when it is still out of service. The Provider can keep the Call active and try to re-establish the call, assuming a temporary communication failure. The application can assume that the Provider tries to re-establish a call if the ProvOutOfServiceEv is not followed exactly by CallInvalidEv and related ConnDisconnect edEv events (that is, if the latter do not follow within a timeout). In addition, some GSM functions can not be easily accessed using the existing JTAPI syntax and method identification. The following new methods or methods with different identifications are defined. Provider getNetworkID () returns the name of the current network. Provider get ServiceLevel () returns the operational service level, NONE, EMERGENCY, FULL. Provider isRoaming () becomes true if the MS is not found in the local PLMN. These new methods allow the application to determine the current public land mobile network (PLMN), the level of the operational service and whether or not the unit is located in the local PLMN. In JTAPI, the Terminal object represents the physical endpoint of the call. It is assumed that the call is a voice carrier. To support the additional call bearers defined by GSM, the additional Terminal subclasses are defined, one for each main bearer type. The DataTerminal subclass of the Terminal represents the physical end point of a GSM data call. The FaxTerminal subclass of the Terminal represents the physical endpoint of a GSM fax call. A typical GSM MS will support at least three terminals, a VOICE terminal, a DATA terminal and a FAX terminal. An MS can support subclasses or additional Terminal instances (for example, an InternalDataTerminal for internal data and a ModemDataTerminal for data sent to a connected PC). Applications accept incoming calls of various bearer types, observing incoming call events in the appropriate Terminal. Now it is described, with reference to the Figure 4, a particular feature that supports a dual-mode GSM call. Figure 4 illustrates details of the JTAPI implementation 18 of Figure 3. Central to the method is the provider method 40. This provider method is interconnected with the operating system 14 in a way that need not be described in detail. As used in this context, a "" method "is a function defined within a class that operates in instances of this class, the provider method 40 has been associated with a voice terminal object 42, a data terminal object. 44, a fax terminal object 46 and an address object 48. When a call is about to be established, the provider method 40 creates a call object 50. The call object 50 creates a local connection object 52. For a connection simple voice, the local connection object 52 creates a terminal connection object 54, which refers to the voice terminal 42. As will be described in more detail, the local connection object 52 can also create a second terminal connection object 56. (and still a third terminal connection object 58). The second terminal connection object 56 refers to the data terminal object 44. The third terminal object 58, if present, can refer to the fax terminal 46. As an alternative configuration, the terminal connection objects , second and third, can be generated for the purpose of creating a fax and data call, as will be described in more detail. It can be seen that if the call is a three way call, the call object 50 will create an additional remote connection object 60 with its own associated terminal connection objects 62-66, as necessary. It can also be noted that if there is another call (for example a call waiting), the provider method 40 can create a second additional call object 70, which will have its own corresponding local connection and terminal connections. In all cases, for a given radiotelephone, there are only three terminals, the voice terminal, the data terminal and the fax terminal. Thus in all cases, the various terminal connection objects created by the local connection 52 and the remote connection 60 and any other remote or local connection, all refer to the respective voice terminal object 42, the data terminal object 44 and the object of the fax terminal 46. In the process to be described, it is the purpose that the GSM transceiver 30 establishes a call with a remote switch over a telephone radio channel and in the case where the call is a mode dual (for example, voice and data or voice and fax) is the purpose for implementing the JTAPI method 18 to establish a call with dual mode capability and to inform the GSM transceiver through the CSPMI 22 that a dual mode call is has established, so that the GSM transceiver 30 can inform the GSM system that the call is a so-called dual mode, so that in turn the GSM system switch, upon receipt of the request to establish a a call makes a call and receives a modem from its interworking function to support the fax or call data functionality. It is also the purpose, to establish this call of dual mode in the promotion of the telephone application 16, using the order of JTAPI cal 1. connect (). In the JTAPI version 1.2, cali. connect () expects an argument that is a terminal object, thus allowing the establishment of a single-mode call to or from that terminal. In order to establish a dual mode call, the preferred embodiment of the present invention allows cali. connect () is changed to add a method that takes a set of terminals as a first argument, instead of a single source terminal. The set of terminals is the argument of the order cali. connect and contains a set of terminal objects which can be a voice terminal and a data terminal or a voice terminal and a fax terminal or a data terminal and a fax terminal or a voice terminal, a terminal data and a fax terminal. When the provider of method 40 is invoked with its command and a set as an argument, it creates the call object 50 and the local connection object 22. Local connection object 22 creates the first and second terminal objects, 54 and 56 The local connection object 52 queries the first terminal connection object 54 for its terminal and the first terminal object 54 answers the local connection object 52 indicating that its terminal (ie, the terminal referred to) is the terminal voice. Similarly, the second terminal connection object 56 is queried by the local connection object 52 and answers by indicating that its terminal is the data terminal. The local connection object 54 informs the calling object 50 that a data terminal connection and a voice terminal connection is established. The call object 50 informs the provider 40 that the dual mode call has been established. The provider 40 informs the GSM transceiver through the CSPMI 22 (via OS 14) that the dual mode call has been established. The provider 40 establishes the call through the transceiver 30 as follows. Provider 40 creates a buffer that has its PlaceCallReq type and adds M / O / C parameters from the following Table 1. These parameters describe the call.

TABLE 1 Name of Parameter Type M / O / C Parameter CallType CALL_TYPE M CalledParty1 PHONE_NUMBER C Repeat Indicator2 REPEAT_INDICATOR O CallType2 CALL_TYPE OR DataParameters' DATA_PARAMETERS C CLIRDisposi t ion4 CLIR_DISPOSITION OR CUGInfo5 CUG INFO 1. Optional for Emergency calls, Mandatory for all other types of calls. 2. Mandatory for Type Calls Multiple Call. 3. Mandatory when any Type of Call is for Fax or Data. 4. Can be included if the client wishes to change the CLIR subscription omission. 5. Can be included if the customer wants to change the CUG subscription omissions. The contents of this buffer are sent through the serial link 22 to the transceiver 30 and, if accepted, the transceiver returns the confirmation message of the following table 2 TABLE 2 Name of the Type of Parameter M / O / C Parameter CallHandle1 CALL HANDLE 1. Mandatory call request if successful. This confirmation message gives call handling which allows the microprocessor 10 to identify the call in subsequent orders. In Table 1, call type 2 indicates an alternate call type and indicates that the alternate call type is data or fax (the initial call type is always voice in GSM). In this way, the provider 40 informs the transceiver 30 that there is an alternate call type and that they are data (alternatively fax). In this way, when the transceiver 30 establishes the call, then the switch is informed that there is an alternate call type and that this type of alternate call requires the reservation of a data modem (or a fax modem). The first input of the first set of terminals is the initially active terminal, but the call is configured to handle it with any of the terminals declared in the set, that is, the terminal connections to the other terminals are placed in the control terminal of the terminal. calls connect ion. bridgestate or (terminalconnection.passivestate). As discussed above, joined / left is used to control the current mode of the call. This variant of connect () is used to support the GSM requirement to initially declare dual mode call parameters (thus requiring application 16 to declare the position of all terminals that can participate in the call). Cali. connect () is changed to add methods to explicitly specify the TON (number type) and the NPI (numbering plan identifier) of the destination address string, if these can not be inferred as described above. Cali. setEmergency () is set to set the emergency mode signal. Cali. setCUGInfo () is defined to specify information of the compact user group in a programmatic form instead of using SS codes (supplementary services) in the destination address chain.

Cali. setCallerldRestricted () is defined to specify the call-line identification restriction requirements in a programmatic form instead of using SS codes in the destination address chain. Call.offHook () is not supported. Applications can not specify the conference or transfer driver. The setTransferController () and setConferenceController () methods produce Met odNotSupported and ge ConferenceControl ler () and getTransferController () returning to < NULL > . The setConferenceEnable (), getConferenceEnable (), setTransferEnable (), and getTransferEnable () manipulate the internal signals that control the ability to transfer or confer this call. The invocations of Cali. consul t () must include the destination address string; the unspecified variant is not supported. Connection. rej ect (int) is defined to allow the application to specify a reason for rejection when it rejects a call. This supports the user's busy functionality determined by the user.

Connection. addToAddress () is not supported. Connect ion. park () is not supported. A terminal connection subclass (data terminal connection) is defined that represents the physical link between the network and the data terminal of the endpoint. The methods are defined to specify and query the data call parameters such as, data transmission rate, modem type, protocol layer, etc. Similarly, a terminal connection subclass ((fax terminal connection,) which is more accurately described as a subclass of media terminal connection), represents the physical link between the network and the terminals of the point final. The methods are defined to specify and query the fax call parameters such as, data weighting, group mode, etc. FaxTerminalConnection also provides specific methods for media to configure fax media stream and transmit data pages and end-of-page indicators. A new Terminal event is defined to allow applications to determine if call progress is active for a specific Terminal "" TermForwardingAct iveEv ". The progress for different services (ie, voice, fax and data) is signaled through the appropriate Terminal object (ie, VOICE, DATA, FAX). It has been mentioned that Provider. createCall () will create a call even if the Provider is OUT_OF_SERVICE since it has not been interrupted and the call can not be placed successfully until the Provider finds IN_SERVICE. This feature is now described in greater detail with reference to Figures 5 and 6. Referring to Figure 5, the case will be considered where, for any reason, application 16 tries to place a call or establish a connection or a session of data in package. The application 16 is typically the interface for the user and may attempt to initiate a call by, for example, when the user turns on the radio device (the mobile station or MS) and dial a telephone number. Application 16 starts the program (or method) illustrated in Figure 5, by calling (invoking) a Provider method. createCall (stage 100) through a Provider order. createCall () through API 30. If, in step 101, the communication device is in an interrupted mode, the program simply returns an error in step 102 and exits in step 103. If the device is not in the interrupted mode, a Call 50 object is created in step 110 and the program in Figure 5 is completed in step 111, ready for the program in Figure 6 to begin. Immediately following the creation of the Call object 50 and without any additional event or condition (and in the absence of any changed event), application 16 calls (invokes) a Cali method. connect () (step 150) through a Cali command. connect () through the API 30. If, in step 151, it is determined that the communications device is out of service, the program (or method) waits in step 152 while other functions execute a scan operation in step 154. A waiting period of approximately 10 seconds is typically sufficient to allow connection to a cellular network in a scanning routine. If, following step 151 or step 156, the communication device has established service with a radio network, step 158 starts and an order is sent to transceiver 30 through serial interface 22 to place the call. The program of Figure 6 ends in step 160. In this way, a user 'is able to start dialing a telephone number to place a call even before the service has been established. This is a particularly useful feature since a typical user wants to start placing a call as soon as the communications device turns on, without considering if the service has been established. The establishment of the service may begin in response to the act of turning on the device (for example, by pressing an energy key or opening a cover) and the methods of Figures 5 and 6 may start in parallel, in response to some other act of the user or the application. It is a significant problem that the JTAPI definition has a separate class for each different JTAPI event. This is a load with the MS defining above 63 event classes, with a total class file of approximately 130 k bytes. According to one aspect of the present invention, the applications are issued based on an event ID instead of the type of event class.

This replaces the multitude of event classes with a much smaller set of event-category classes. Applications use the event ID to determine a specific event within a broad type. This results in significant space saving without any significant loss of object encapsulation. The event classes are grouped into eight generic classes as follows: - EV - base class of all events. - ProvEv - provider events. CallCtlAddrEv - call and address control address events. - CallCtlCallEv - call and call control call events. - CallCtlConnEv - call and connection control connection events. - CallCtlTermEv - call control terminal and terminal events. CallCtlTermConnEv - call control terminal connection and terminal connection events. - MediaEv - media events. The specific events grouped in these generic classes are set out in the following table 3, TABLE 3 EV - called base of all ProvEv - events of the events. ProvInServiceEv provider ProvObservationEndedEv ProvOutOfServiceEv ProvShutdownEv CallCtlAddrEv - CallCtlCallEv events - events address call control and call control address and Call AddrEv CallEv CallCtlEv CallCtlEv AddrObservationEndedEv CallActiveEv Cal1CtlAddrDoNotDisturbEv CallInvalidEv CallCtlAddrForwardEv CallObservationEndendEv CallCtlAddrMessageWaitingEv TABLE 3 cont. CallCtlConnEv CallCtlTermConnEv ConnEv TermConnEv CallCtlEv CallCtlEv ConnAler ingEv TermConnActiveEv ConnConnectedEv TermConnCreatedEv ConnCreatedEv TermConnDroppedEv ConnDisconnectedEv TermConnPassiveEv ConnFai1edEv TermConnRingingEv ConnlnProgressEv TermConnUnknownEv ConnUnknownEv CallCtlTermConnBridgedEv CallCtlConnAlertingEv CallCtlTermConnDroppedEv CallCtlConnDialingEv CallCtlTermConnHeldEv CallCtlConnDisconnectedEv CallCtlTermConnlnUseEv CallCtlConnEstablishedEv CallCtlTermConnRingingEv CallCtlConnFailedEv CallCtlTermConnTalkingEv CallCtlConnlnitiatedEv Cal1Ct1TermConnUnknownEv CallCtlConnNetworkAlertingEv CallCtlConnNetworkReachedEv CallCtlConnOfferedEv CallCtlConnQueuedEv Cal1Ct1ConnUnknownEv CallCtlTermEv MediaEv TermEv MediaTermConnAvailableEv CallCtlEv MediaTermConnDtmf Ev TermObservationEndedEv MediaTermConnEv CallCtlTermDoNotDisturbEv MediaTermConnStateEv Medi aTermConnUnavai 1 abl eEV In summary, a telephony API has been described for a wireless communications device and an associated implementation that includes a provider method, which is highly suitable for developing the object-oriented computer programs for invoking wireless telephony functions. Using an API that allows a high degree of portability through platforms and in an implementation that has a very low memory requirement. In addition, the dual-mode calling functionality, as required in the GSM radiotelephone system, is supported using a standard JTAPI event class used hitherto to establish simple, wireline telephone calls. According to one aspect of the invention, a radio communication device has been described which comprises a memory that has a user application program and a mobile telephony program stored therein. The mobile phone program maintains parameters that describe a wireless network to which the device is connected. These parameters include one or more of: a name of a current network; a level of operational service of the current network and an indication of whether the current network is a local network. These parameters can be supplied to the mobile telephony program from a transceiver or through a mobile internet protocol connection. An application program interface between the user application program and the mobile telephony program has at least one command (for example, Provider.getNetworkID (); Provider.getServiceLevel () or Provider.isRoaming ()) to call these parameters and return them to the application program. The foregoing description has been given by way of example only and modifications of detail may be made within the scope and spirit of the invention.

APPENDIX 1 The JAVA Telephony API A Summary Version 1.2 Introduction The JAVA Telephony API (JTAPI) is a targeted, portable object application programming interface for JAVA-based computer-telephony applications. JTAPI serves a wide audience, from call center application developers to web designers. JTAPI supports both first and third party telephony application domains. The API is designed to make simple programming applications easy, while providing those features necessary for advanced telephony applications. The JAVA Telephony API is, in fact, a set of API's. The "core" API provides the basic call model and rudimentary telephony features, such as placing phone calls and answering phone calls. The core API is surrounded by standard extension APIs that provide functionality for specific telephony domains such as call centers and continuous access to media. The architectures of the extension package and the JTAPI core are described later in this document. Applications written using the JAVA Telephony API are carried through various computer platforms and telephone systems. The JTAPI implementations will be available for existing computer-telephony integration platforms such as, Sun Microsystem SunXTL, Intel and Microsoft TAPI, Lucent TSAPI and Novell and IBM CallPath. In addition, independent hardware vendors may choose to provide implementations of the JAVA Telephony API in addition to their own hardware. Document Organization Summary This document is organized into the following sections: Characteristics of the Java Telephony API - 'Describes the characteristics of JTAPI and the principles in which it was designed. Supported Configurations - Summarizes the environments in which JTAPI can be used and the configurations of the computer and the software for which it was designed. Architecture of the JAVA Telephony Package - summarizes how the JAVA Telephony API is organized in several JAVA language packages. A brief description accompanies each package along with links for more detailed documentation. The JAVA Telephony Call Model Describe how phone calls and the different objects that retrieve phone calls are represented in this API. Core Package Methods - Provides a brief summary of the key methods available in the core package, which perform the most basic telephone operations such as placing a phone call, answering a phone call, and disconnecting a connection to a phone call. Connection Object States - Describes the states in which the Connection object can exist. This provides a description of the permissible transitions of each state. TerminalConnection Object States - Describes the states in which the. TerminalConnection object may exist. This provides a description of the permissible transitions of each state. Place a Phone Call - One of the most common features used in any telephony API is to place a phone call. This section describes the JTAPI method invocations required to place a phone call and examines the state changes in the call model. This analysis will explain how calls are placed, answered and terminated. The Java Telephony Observer Model Describes the JTAPI observer model. The applications use observers for asynchronous notification of changes in the state of the JTAPI call model. The examples of application code are not included here, but two examples of real-life code that use the Java Telephony API can be found in the Java Telephony API Version 1.2 Summary published by Sun Microsystems, Inc. of Palo Alto, California . An example places a phone call to a specified phone number. The other example shows a designated Terminal that answers an incoming phone call. Location and Obtaining Providers Describes the manner in which applications are created and objects from the JTAPI Provider are obtained.

Security - Summarizes the security strategy of the JTAPI. Characteristics of Java Telephony The characteristics and guiding design principles for the JAVA Telephony API are: Bring simplicity to the most basic telephony applications. Provide a scalable scheme that extends desktop applications to the telephony applications of the distributed call center. Interconnect applications directly to service providers or act as a Java interface for existing telephony APIs such as, SunXTL, TSAPI and TAPI. It is based on a simple kernel that is augmented with standard extension packages. It works in a wide range of hardware configurations, wherever the Java process time can be used. Supported Configurations The JTAPI works in a variety of system configurations, including centralized servers with direct access to telephony resources and remote network computers with access to telephony resources over a network. In the first configuration, a network computer is running the JTAPI application and is accessing the telephony resources through a network, as illustrated in Figure 7. In the second configuration, the application is working in a network. computer with its own telephony resources, as illustrated in Figure 8. Computer Network Configuration (NC) In a network configuration, the JTAPI application or Java applet works on a remote workstation. This workstation can be a network computer with only a screen, keyboard, processor and some memory. This accesses the network resources, making use of a centralized server that manages telephony resources. The JTAPI communicates with this server through a remote communication mechanism, such as Java Remote Method Invocation (RMI), JOE or a telephony protocol.The following diagram shows this configuration. Configuring the Desktop Computer In a desktop configuration, the JTAPI application or Java applet works on the same workstation that hosts the telephony resources Figure 8 shows the desktop configuration Java Telephony Package Architecture Java Telephony API is composed of a set of Java language packages, each package provides a specific piece of functionality for a certain aspect of computer-telephony applications, implementations of telephony servers choose the packages they support, depending on the capabilities of your core hardware and platform. Applications can check the packages supported by the implementation they currently use. In addition, application developers can deal with only the supported package applications needed to carry out the task. Figure 9 represents the architecture of the JTAPI packets. At the core of the Java Telephony API is the "core" package. The core package provides the basic scheme for model telephone calls and rudimentary telephony features. These features include placing a phone call, answering a phone call and disconnecting a connection to a phone call. Simple telephony applications will only need to use the kernel to carry out their tasks and do not need to deal with the details of other packages. For example, the core package allows applet designers to add telephone capabilities to a Web page with ease. A number of "standard extension" packages extend the JTAPI core package. Each of these extension packages brings additional telephony functionality to the API. Currently, the following extension packages exist for this API: call control, call center, media, telephone, private data and capacity packages. Each package is summarized below in terms of the features it brings to the JTAPI and is linked to a separate summary document and specifications. The architecture of the JTAPI package is a two-way street for both implementations and applications. In other words, the telephony server implementations choose which extension packages (in addition to the core package) they implement, based on the fundamental hardware capabilities. The applications choose the extension packages (in addition to the core package) that they need to use to carry out the desired tasks of the application. The applications can consult the implementation for the extension packages that the implementation supports and the developer of the application does not need to deal with details of some packages not necessary for the application. Java Telephony Standard Extension Packages Each JTPI extension package has its own specification that describes its extensions to the core API and in most cases has its own separate summary document that describes them. The diagram below lists each available extension package, with a link to the individual summary document, if it exists. Call Control Package The j avax package. telephony. callcontrol extends the core package by providing more advanced call control features such as placing calls on hold, transferring phone calls and conferencing phone calls. This package also provides a more detailed state model of phone calls. Call Center Package The j avax package. telephony. callcenter provides applications the ability to execute advanced features needed to manage large call centers. Examples of these advanced features include: Addressing, Automatic Call Distribution (ACD), Predictive Call and application data of association with telephony objects. Media Package The j avax package. telephony. media provides access to applications to media streams associated with a phone call. They are able to read and write data from these media streams. DTMF (touch-tone) and non-detection of DTMF tone and generations is also provided in the j ava package. telephony. half . Phone Package The j avax package. telephony. hone allows applications to control the physical characteristics of telephone sets with telephone hardware. Implementations can describe Terminals as collections of components, where each of these component types has an interface in this package. Capabilities Package The j avax package. telephony. capabi 1 i ties allows applications to consult if certain actions can be executed. Capabilities take two forms: static capabilities that indicate whether an implementation supports a feature; dynamic capabilities that indicate whether a certain action is permissible in the current state of the calling model. Private Data Package The j avax package. telephon. privatedata allows applications to communicate data directly with the fundamental hardware switch. This data can be used to instruct the switch to execute a specific switching action. Applications can also use the package to "transport" a piece of data with a Telephony API object Java. Java Telephony Call Model The JTAPI call model consists of half a dozen objects. These objects are defined using Java interfaces in the core package.

Each call model object represents either a logical or physical entity in the telephone world. The main purpose of these call model objects is to describe the telephone calls and endpoints included in a telephone call. These call model objects relate to each other in specific ways, which is summarized below and described in more detail in the kernel package specification. Figure 10 shows the call model JTAPI and the objects that make up the call model. A description of each object follows the diagram. Purpose of the Provider The object of the provider is an abstraction of the telephony service provider's software. The provider can administer a PBX connected to a server, a telephony / fax card in a desktop machine or a network operation technology of the computer such as IP. A provider hides the specific service aspects of the telephony subsystem and allows Java applets and applications to interact with the telephony subsystem in a manner independent of the device.

Call Object The Call object represents a telephone call, the information flowing between the service provider and the call participants. A telephone call comprises a Call object and zero or more connections. In a two-part call scenario, a phone call has a Call object and two connections. A conference call is three or more connections associated with a Call object. Address Object The Address object represents a telephone number. It is an abstraction for the logical end point of a telephone call. Note that this is too different from the physical endpoint. In fact, an address can correspond to several physical endpoints (ie Terminals). Connection Object A Connection object models the communication link between a Call object and an Address object. This relationship is also referred to as a "logical" view, because it deals with the relationship between the Call and the Address (that is, a logical endpoint). Connection objects can be found in one of several states, indicating the current state of the relationship between the Call and Address, These Connection states are summarized below. Terminal Object The Terminal object represents a physical device such as a telephone and its associated properties. Each Terminal object may have one or more Address objects (telephone numbers) associated with it, as in the case of some office telephones capable of managing multiple call appearances. The Terminal is also known as the "physical" endpoint of a call, because it corresponds to a physical piece of hardware. TerminalConnection Object The TerminalConnection objects model the relationship between a Connection and the physical endpoint of a Call, which is represented by the Terminal object. This relationship is also known as the "physical" view of the Connection (in contrast to a Connection, which models the logical view). The TerminalConnection describes the current state of the relationship between the Connection and a Particular Terminal. The states associated with the TerminalConnection are described later in this document. Core Package Methods The core package defines three methods to support its main features: placing a phone call, answering a phone call, and disconnecting a connection to a phone call. These methods are Cali. connect (), TerminalConnect ion. answer () and Connection. disconnect (), respectively Cali. connect () Once an application has an inactive call object (obtained through the Provider. createCall ()), you can place a phone call using the Cal 1. connect () method. The application must specify the origin Terminal (physical end point) and the source address (logical end point) in that terminal (in the case where a Terminal has multiple telephone numbers in it). It also provides the string of the destination telephone number. Two Connection objects are returned from the Cali method. connect (), which represent the origin and destination endpoints of the telephone call. TerminalConnection. answer () Applications are monitored with observers (discussed later) in the Terminal for when incoming calls are presented. An incoming telephone call to a Terminal is indicated by a TerminalConnection to this Terminal in the CALL state (see TerminalConnection states below). At this time, applications can invoke the TerminalConnect ion. answer () to answer that incoming phone call. Connection. disconnect () The Connection method. disconnect () is used to remove an address from the phone call. The Connection object represents the relationship of that Address with the telephone call. Applications typically invoke this method when the Connection is in the CONNECTED state, resulting in moving the Connection to the DISCONNECTED state. In the core package, the application can only withdraw complete Call Directions and all Terminals associated with this Address that are part of the call are also removed. The call control extension package provides the ability for your application to remove individual terminals from the Call only.

Connection Object States A Connection object is always in a state that reflects the relationship between a Call and a Direction. The state in which a connection exists is not only important for the application for information purposes, but it is always an indication of which methods and actions can be invoked in the connection object. The state changes that Connection objects experience are governed by rules shown below in a state transition diagram. This diagram guarantees to the developers of the application the possible states in which the Connection object can transit in some given current state. These state transition rules are invaluable to the developers of the application. Figure 11 shows the possible state transitions for the Connection object. Follow a brief summary of the meaning of each state. INACTIVE State The INACTIVE state is the initial state for all new Connection objects. Connections typically move quickly out of the INACTIVE state to another state. A connection in the INACTIVE state indicates that the party has just joined the telephone call, in some way. No core method is valid in Connections in the INACTIVE state. Status IN PROGRESS The status IN PROGRESS indicates that a telephone call is currently being placed at its destination endpoint. Status ALERT The ALERT state indicates that the destination party is alerted to a telephone call for an incoming phone call. Status CONNECTED The CONNECTED state indicates that a party is actively part of a telephone call. A Connection in the CONNECTED state implies that the associated party is talking to the other parties in the call or connects to give tone. Status DISCONNECTED The DISCONNECTED status indicates that a part is no longer part of a telephone call. No method is valid for Connections in the DISCONNECTED state. FAILED State The FAILED state indicates that a telephone call placed at the endpoint has failed.

For example, if an application uses Cali. connect () to place a phone call to a party that is busy, the Connection associated with the called party transits to the FAILED state. UNKNOWN State The UNKNOWN state indicates that the Provider can not determine the status of the Connection at the current time. A Connection can transit in and out of the UNKNOWN state at any time, unless it is in any of the states, DISCONNECTED or FAILED. The effects of invoking any method in a connection in this state are unpredictable. TerminalConnection Observer States The TerminalConnection object represents the relationship between a Terminal and a Connection. As previously mentioned, these objects represent a physical view of the Call, which describes which physical endpoints of the Terminal are part of the telephone call. Similar to Connection objects, TerminalConnection objects have their own set of states and state transition diagram. A state transition diagram is shown in Figure 12 and a brief description of each state is given below. INACTIVE State The INACTIVE state is the initial state for all TerminalConnection objects. It has the same connotation for the INACTIVE state of the Connection object. ACTIVE State The ACTIVE state indicates that a Terminal is an active part of a telephone call. This often means that the handset of the terminal is off-hook. Status in CALL The state in CALL indicates that a Terminal is signaling to a user that an incoming telephone call is presented in the Terminal. SUSPENDED status The SUSPENDED status indicates that a Terminal was once part of a telephone call, but has already been suspended from this telephone call. The SUSPENDED state is the final state for all TerminalConnect ions. PASSIVE State The PASSIVE state indicates that a Terminal is part of a telephone call, but not in an active manner. A TerminalConnection in the PASSIVE state indicates that a resource in the Terminal is being used by this telephone call. Packages that provide advanced features allow Terminals to join calls from the PASSIVE state. UNKNOWN State The UNKNOWN state indicates that the Provider is unable to determine the current status of a TerminalConnection. It has a connotation similar to that of the UNKNOWN state of the Connection object. Place a Telephone Call The various previous sections have summarized the JTAPI call model, the essential methods in the core packet, and the states of the Connection and TerminalConnection. This section unites all this information, presenting a common scenario found in most telephony applications. This section describes the state changes that the full call model typically experiences when an application places a simple phone call. Readers will leave with a consistent understanding of the call model changes for this simple example.

The vehicle used to describe the states experienced by the call model is shown in Figure 13. This diagram is a timing diagram of the call model, where changes in the various objects are represented as increments of times below the vertical axis . This diagram shows the typical state changes after an application invokes the Cali method. connect (). In Figure 13, the discrete time stages are denoted by integers below the vertical axis. The time increases below this axis, but does not mean that the integers indicate the real time (clock). Figure 13, as a set, represents a single telephone call. In this case, the diagram represents a two-part telephone call (The Cal 1. connect () method always results in a two-part call). The diagram can be divided into two parts: the left half and the right half. The left half represents the originating end of the telephone call and the right half represents the destination end of the telephone call. On the left (origin) side of the diagram, the two vertical lines represent the Terminal objects and Source address (which are arguments for the Cali. Connect () method, as indicated in the diagram. The horizontal lines represent either Connection objects or TerminalConnection objects as marked. Note that the Connection objects are plotted, in the innermost regions, while the TerminalConnection objects are plotted in the outermost regions. Similarly, on the right (destination) side of the diagram, the two vertical lines represent the Terminals and Destination Address. In this example, there are two destination terminals associated with the Destination Address. This configuration has been previously represented in Figure 10. Note that there are already two Terminals, there are two TerminalConnection objects on the destination side. Figure 13 can be read as follows: As the time passes, the Connection and TerminalConnection objects change states. The appearance of a new horizontal line of Connection or TerminalConnection corresponds to a new object of this type that is created.

In the example of placing a phone call, we note that after the two Connections are created in the inactive state, the Source Connection transits to the CONNECTED state, while the Destination Connection transits to the state IN PROGRESS. At this time, a TerminalConnection is created towards the originating Terminal and transits to the ACTIVE state. When the Destination Connection transits to the ALERT state, two TerminalConnect ions are created in the CALL state. At this point, a person at one of the destination terminals answers the call. When this happens, this TerminalConnection moves to the ACTIVE state and the other TerminalConnection moves to the PASSIVE state. At the same time, the destination connection moves concurrently to the CONNECTED state. When the phone call ends, all Connections move to the OFF state and all TerminalConnect ions move to the SUSPENDED state. As a final point, this document has used the terms "logical" and "physical" view of a telephone call. This diagram makes these concepts clear. An application can monitor the status changes of the Connection object (that is, the logical view). By looking at the diagram, the reader can understand that these states provide a higher level view of the progress of the telephone call. The status changes of the TerminalConnection represent the physical view. By monitoring the status changes of TerminalConnection, applications can see what is happening at each physical terminal point. Java Telephony Observer Model The Java Telephony API uses the observer / observable Java model to notify asynchronously the application of several changes in the JTAPI call model. These changes can include changing the state of an object or creating an object. The objects of the Provider, Call, Terminal and Directorate have Observers. The interfaces that correspond to these observers are ProviderObservers, CallObserver, TerminalObserver and AddressObserver, respectively. The ProviderObserver reports all status changes to the Provider object. For the core package, status changes are represented when the Provider changes status from OUT_OF_SERVICE to IN_SERVICE to SUSPEND. The Call Observer reports the status change information for all Connections and TerminalConnection that are part of the phone call as well as status changes to the Call itself. These state changes are not reported in the Address objects or Terminal objects. Sometimes, the application may want to monitor the Address or Terminal objects for incoming phone calls. In these cases, the application uses the Address methods. addCallObserver () or Terminal addCallObserver (). These methods instruct the implementation to automatically add a CallObserver to any of the calls that arrive at an Address or Terminal. These CallObservers are removed once the call leaves the Address or Terminal. The Direction and Terminal observers report any change of state in these objects. In the core package there are no events for these objects. The interfaces of AddresObserver and TerminalObserver still exist, however, so other packages can extend these interfaces.

Locating and Obtaining Suppliers The Java Telephony API defines a convention by which JTAPI telephony server implementations make their services available for applications. The two elements that link an application to a server are: Jtapi PeerFactory The JtapiPeerFactory class is the first point of contact for an application that needs telephone services. It has the ability to return a named JtapiPeer object or a default JtapiPeer object. It is defined as a static class. JtapiPeer The JtapiPeer interface is the basis for a particular implementation of the Java Telephony API vendor. Each vendor that provides a JTAPI implementation must implement this interface in a class that can be loaded by the JtapiPeerFactory. It is through a class that implements the JtapiPeer object, that an application obtains a Supplier object. JtapiPerrFactory: Getting Startup The JtapiPeerFactory is a static class defined in JTAPI. Your exclusive public method, getJtapiPeer () gets the required JtapiPeer implementation or returns an omission implementation. getJtapiPeer () takes the name of the desired JTAPI server implementation as a parameter to return an object example of this class. If no name is provided, getJtapiPeer () returns the implementation object of the JTAPI server by default. JtapiPeer: Obtaining a Supplier Object JtapiPeer is an interface. It is used by implementers of the JTAPI server. It defines the methods that the applications use to obtain objects from the Provider, to consult the services available in those suppliers and to obtain the name of the object instance of JtapiPeer. When creating a class that implements the JtapiPeer interface, JTAPI implementations make the following methods available for applications. The applications use the JtapiPeer method. getProvider () to obtain new Provider objects. Each implementation can support one or more different "services" (for example, for different types of fundamental network substrates). A list of available services can be obtained through the JtapiPeer method. getServices (). Applications can also provide optional arguments to the Provider. These arguments are appended to the string argument passed to the JtapiPeer method. getProvider (). The chain argument has the following format: <; service yam >; argl = valí; : arg 2 = val2; ... where < service yam > it is not optional and each optional argument pair that follows is separated by a semicolon. The keys for these arguments are of specific implementation, except for two standard defined keys: l.login: provides the name of the user to enter the Provider. 2.pass d: Provide a password to the Provider. The applications use the JtapiPeer method. getName () to obtain the name of this JtapiPeer object instance. It has a name parameter, which is the same name used as an argument to the JtapiPeerFactory method. getJtapiPeer (). Security in the Java Telephony API 52 - JTAPIpeer implementations use the Java "sandbox" model to control access to sensitive operations. Callers of JTAPI methods are classified as "reliable" or "unreliable", using criteria determined by the system of duration of operation. Reliable callers are allowed full access to JTAPI functionality.

Unreliable callers are limited to operations that can not compromise the integrity of the system. JTAPI can be used to access deployments or telephony servers that provide their own security mechanisms. These mechanisms remain in place; Parameters such as password and user name are provided through parameters in the JtapiPeer method. getProvider ().

Claims (14)

1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and therefore the property described in the following claims is claimed as property. 1. A radio communication device is characterized by: a memory that has stored in it a user application program and a telephony program, which in operation, has a plurality of terminal objects; and an application program interface (API) between the user application program and the telephony program, where the API has the order to establish a call and where the telephony program accepts, as an argument of the order for establishing a call, a set identifying a plurality of terminal objects, thus allowing the establishment of a call for a plurality of terminal objects.
2. 2. The device according to the claim 1, characterized in that the plurality of terminal objects is selected to be at least two different terminal objects of the group comprising voice terminal objects, fax terminal objects and data terminal objects, thus allowing the establishment of a call in dual mode.
3. The device according to claim 1, characterized in that it has at least speech elements controlled by a first terminal object of the plurality of terminal objects and data elements controlled by a second terminal object of the plurality of terminal objects.
4. The device according to claim 3, characterized in that it also includes a first processor that has a virtual machine, in which at least the telephony program works and a second processor that has transceiver software that operates in it that controls the elements of voice and data elements.
5. The device according to claim 4, characterized in that it also includes a serial link between the first processor and the second processor.
6. 6. The device according to the claim 4, characterized in that it further includes a link between the first processor and the second processor, wherein the link identifies for the transceiver software that an order to establish a call is one of a main type and an alternate type, wherein an alternate type indicates a call of dual mode.
7. 7. In a radio communication device, a method for establishing a dual mode call characterized in that: it invokes, from an application program through an application program interface (API), a call connection class that uses an order having an argument comprising a set, wherein the set comprises a plurality of terminal objects of different types selected from a type of voice, a type of fax and a data type.
8. The method according to claim 7, characterized in that it further includes the step of, in the call connection class, invoking a first connection object that refers to a voice terminal and a second connection object that refers to a data terminal and a fax terminal.
9. The method according to claim 7, characterized in that the application program is further capable of interconnecting with a call connection class that does not support the establishment of a dual mode call by using an order that has an argument comprising an object of single terminal.
10. The method according to claim 7, characterized in that the call connection class is capable of being invoked by an order having an argument comprising a single terminal object, thus establishing a single mode call.
11. 11. A radio communication device, characterized in that: a memory that has stored in it a user application program and a telephony program, the telephony program having a set of defined events, each event having an event identifier defined ( ID), grouping together the set of events defined in (a) a base class, (b) a provider event class, (c) a class of call control and address events, (d) a class of call control and call call events; (e) a class of call and connection control connection events, (f) a class of call control terminal and terminal events, (g) a class of call control terminal connection events and connection of terminal and (h) a class of media events and an application program interface (API) between the user application program and the telephony program, where the API accepts an application program command, defining the order one event class of one of groups (a) to (h) together with an ID that defines an event within the event class.
12. The radio communication device according to claim 11, characterized in that each defined event has a computer program that defines a method and wherein all the computer programs for the methods corresponding to events of a defined set of events are included within of a class object, without being sub-defined in objects at any level lower than the class object.
13. 13. A method of operation of a radio communication device comprising a memory that has stored in it a user application program and a telephony program, characterized by the method by: calling a program in the telephony program to create an object call and create the call object without considering whether the radio service for the radio device has been established; and calling a program in the telephony program to start placing a call but waiting for a service to be established by radio if the radio service has not been established. The method according to claim 13, characterized in that it also includes the step of returning an error to the application program if the service has not been established following a delay after calling the program in the telephony program to begin placing the call.