A Method and Apparatus for Establishing Compatibility Between Communication Applications Producing at Commands and a Telephony Application Programming Interface

1. Field of the Invention

The present invention relates to an interface which enables data communication for a computer system using a Windows.TM. operating system ("Windows.TM."). More particularly, the present invention relates to an apparatus and method for enabling communication software applications currently sold in the commercial marketplace, to utilize a Telephony Application Programming Interface ("TAPI"), a Windows.TM. Open System Architecture component, in order to support AT command set processing.

2. Background of the Invention

Data communication schemes primarily utilize conventional modems in combination with communication software applications ("communication applications") in order to transfer information between two sources, typically two computer systems. Being an embedded system, the conventional modem commonly features a non-programmable hardware chip set (e.g., a Rockwell chip set) which generally determines its functional aspects.

The procedure for transferring information begins with a user selecting a specific communication operation to occur, such as dialing a phone number or answering a telephone call. These and other communication operations are currently being supported by current communication applications such as ProComm, Crosstalk and the like. In response to the selection, the communication application generates a command, namely an AT command, corresponding to the selected communication operation. The AT command is a character string comprising at least an AT command identifier which identifies a particular operation selected by a user. Examples of such AT command identifiers include, but are not limited to, ATD (i.e., dial the phone), ATA (i.e., answer the phone), ATL (i.e., control speaker volume) and the like. The AT command identifier, forming the initial characters of the AT command, is usually followed by a string of characters used to engage or disengage phone line connections, to induce signal connection delays or to provide various telephony features. The AT command is terminated by any predetermined end-of-line ("EOL") character.

Referring to FIG. 1, a detailed diagram of a conventional prior art communication scheme is illustrated in which specific telephony operations between a computer system 1 and a second source 10 are performed. In order to perform the specific telephony operation between the two sources 1 and 10, the communication application 2 first generates a particular AT command 3, corresponding to the specific operation. The AT command 3 is then inputted into a communication port 4. The communication port 4 is a standard interface between a host 5 and an input/output ("I/O") board 6 (e.g., a modem card, fax card, digital signal processor cards, etc.) to enable communication therebetween. The communication port 4 passes the AT command 3 to a conventional communication task 7 which controls and performs the specific operation required from the I/O board 6.

In general, a "task" is application level code within an operating system for managing hardware by reading information from one device, processing the information and sending the information to another device. Here, the conventional communication task 7 is a combination of software and hardware, generally comprising a non-programmable hardware chip set, which receives the AT command 3 as an input. Based on the nature of the AT command 3, the conventional communication task 7 directly performs the specific operation to be sent over analog public phone lines 9a-9n to accomplish the specific operation.

As illustrated in FIG. 1, the conventional communication scheme is bi-directional, allowing status codes commonly used in the art to be sent from the conventional communication task 7 through the communication port 4 and into the communication application 2, resulting in a subsequent operation being performed or a display message to occur.

Recently, however, in a joint-venture between Intel.TM. Corporation and Microsoft.TM. Corporation, these companies created a Telephony Application Programming Interface (hereinafter referred to as "TAPI"). TAPI is a high level programming interface for Windows.TM. which supports many types of telephony operations associated with conventional analog public phone lines, digital medium such as digital Public Branch Exchange ("PBX") phone lines, ISDN phone lines and eventually wireless medium. As a result, TAPI allows a communication application to support numerous telephony operations through a variety of mediums by simply making a function call to TAPI which will drive the hardware (fax/modem card, DSP card, network to switch and then like) coupled thereto. An article in December's issues of Microsoft Systems Journal describes the operation of TAPI in great detail.

In view of the overwhelming endorsements of TAPI by the telecommunication market, it is quite likely that many communication applications will be created to utilize TAPI. However, no communication scheme has been created, or even contemplated, to enable previously designed communication applications to be compatible with TAPI. Moreover, no communication scheme has been designed to allow DOS-based communication applications to use TAPI because TAPI exclusively operates in Windows.TM..

In light of the foregoing, it is appreciated that there exists a need to design and develop a communication scheme which would enable numerous communication applications, including DOS-based applications, to use TAPI services without modifying the source code of these applications. Thus, it would be a great advantage and is therefore an object of the present invention to provide a data communication interface which would operate as an intermediary between TAPI and the non-TAPI communication applications.

The present invention relates to an apparatus and method for providing a communication scheme which supports AT command set processing to enable off-the-shelf conventional communication applications developed concurrently and prior to TAPI, to be TAPI compatible. The apparatus includes a communication task which identifies an AT command and passes a control message to an application operating transparent to the user (i.e., the "Daemon" application). The Daemon application reads the control message and logically maps the control message into a TAPI function call which is transmitted to TAPI. The apparatus operates in a bi-directional manner so that the Daemon application also receives TAPI result code messages and thereafter, translates the TAPI result code messages into status messages readable by the communication task. Upon receipt of the status messages, the communication task converts the messages into conventional status codes which are sent to the conventional communication application.

The objects, features and advantages of the present invention will become apparent from the following detailed description of the present invention in which:

FIG. 1 is a block diagram of a conventional data communication scheme.

FIG. 2 is a block diagram of one embodiment of an AT command.

FIG. 3 is a block diagram of the present invention providing a communication data path between a communication application and TAPI.

FIG. 4 is a block diagram of the present invention which provides specific detail of the elements of the present invention passing the information in search of an AT command.

FIG. 5 is a flowchart of the execution process by the AT Command task.

FIG. 6 is a flowchart of the execution process by the Daemon application.

A communication scheme is described for enabling existing data communication applications to use TAPI in order to support AT command set processing. In the following detailed description, numerous specific details are set forth, such as a specific configuration of the data communication scheme. It is apparent, however, to one skilled in the art that the present invention may be practiced without incorporating this specific configuration.

The present invention need not be limited for use in connection with an external I/O board, but may be alternatively used with a virtual device driver for Windows.TM., wherein the virtual device driver would intercept an AT command generated from a communication application so that all necessary translations are performed on the host. Moreover, it should be noted that there exist some instances where well-known circuits, process steps and the like are not set forth in detail in order to avoid unnecessarily obscuring the present invention. Instead, a specific example has been created for the sole purpose of illustrating the operation of the present invention, but is in no way a limitation on the scope of the present invention.

As previously discussed herein, FIG. 1 illustrates the conventional communication scheme used to establish a communication link between the computer system 1 and a second sources 10 through conventional analog public telephone lines 9a-9n. Upon request by the user, the communication application 2, being controlled by Windows.TM. on the host 5, generates an AT command 3 corresponding to a specific telephony operation. The AT command 3, as previously defined, includes an AT command identifier 11 followed by the data string 12 having a plurality of characters as shown in FIG. 2. For example, if the specific telephony operation was directed toward dialing a phone in order to make a phone call, the AT command 3 would include an AT command identifier 11 "ATD" (i.e., an AT command corresponding to a dial request) followed by the data string 12; namely, a plurality of characters indicating a destination of the phone call (i.e., international or local area codes, if either is applicable) 12a, a phone number 12b, as well as other information (e.g., characters imposing delay information, access request characters to establish a connection with the public phone lines, etc.) necessary to establish a proper phone line connection. The AT command 3 is terminated by the end-of-line ("EOL") character 13. The data string shown in FIG. 2 will be used for illustrative purposes later in the application.

Referring back to FIG. 1, the AT command 3 is inputted into the conventional communication task 7 through the communication port 4. The conventional communication task 7 performs necessary operations to achieve the specific telephony operation. For example, taking the "dialing" example as an illustration, the conventional communication task 7 would be required to generate audible dial tones to establish a telephone connection over the analog public telephone lines 9a-9n. The communication scheme of the present invention is substantially different from this conventional communication scheme as illustrated in FIG. 3.

In FIG. 3, a block diagram of the present invention is illustrated. As previously discussed, the purpose of the present invention is to enable communication applications currently in the marketplace to utilize TAPI services. As similarly shown in FIGS. 1-2, when a specific telephony operation is desired between at least two sources, namely a computer system 20 and a second device 31, a communication application 21 running in Windows.TM., DOS.TM. and the like on the host 27 sends an AT command 22 corresponding to the specific telephony operation into the communication port 23, being an interface between the host 27 and a I/O board 30. The communication port 23 relays the AT command 22 into a communication task 24 operating in a standard real time operating system, such as SPOX.TM. which provides an infra-structure to support tasks and mailboxes.

However, contrary to the operations of the conventional communication task 7 in FIG. 1 which directly performs the specific operation, the communication task 24 intercepts the AT command 22 and generates a corresponding control message to be passed into an application 26 executable in the host 27. The application (hereinafter referred to as the "Daemon" application) 26 operates in Windows.TM. in a manner undetected by the communication application 21 and the user. After receipt of the control message 25 from the communication task 24, the Daemon application 26 logically maps the control message 25 into corresponding TAPI function calls 28 and passes the TAPI function call into the TAPI interface 29. Upon receipt of the corresponding TAPI function call 28, the TAPI interface 29 passes information within the TAPI function call 28 to an associated device driver to assist the I/O board 30 or another hardware device to perform the specific telephony operation.

Referring to FIG. 4, a more detailed block diagram of certain data processing elements of the present invention is illustrated; namely, the communication port 23 and the communication task 24. The communication port 23 and the communication task 24 are shown in more detail in order to provide a better understanding of the translation of the AT commands 22, which are generated by the communication application 21, into the control messages 25 being outputted to the Daemon application 26. In addition, source code pertaining to the operations of the communication task 24 (Appendices B & C) and the Daemon Application 26 (Appendix D) are included in order to provide better understanding of their operations. However, it is contemplated that a person skilled in the art could modify the source code in order to provide similar functionality so that such code should not be interpreted as a limitation on the present invention.

As stated above, the communication application 21 sends the AT command 22 into the communication port 23. Unlike the conventional communication scheme, the communication port 23 in the present invention is an Application Specific Integrated Circuit ("ASIC") 40 designed to provide an interface identical to a serial UART, generally a 16550 UART which is a standard interface used by a majority of the conventional modems. The ASIC 40 is driven by a communication port driver 41 which supports digital signal processing functions so that the communication port driver 41 and the ASIC 40 function in combination as a device similar to the 16550 UART.

The communication driver 41 is a streaming driver which is responsible for retrieving information from the ASIC 40 and for providing such information to a Communication Port Manager task (hereinafter referred to as "Communication Manager") 42 in order to allow AT command set processing while on-line with a remote modem. As information is transferred from the communication application 21 into the communication port driver 41 through the ASIC 40, the information is stored in a plurality of buffers 44a-44n referenced by the communication driver 41 through pointers. Thereafter, the pointers referencing the stored information can either be passed to the Communication Manager 42 or to queues for subsequent data transfers.

The Communication Manager 42 is a task which performs ASIC communication port management including, but is not limited to, processing and editing data, translating messages from and to an AT Command task 43 and the like. This management is accomplished through sequential operation of various routine calls, wherein the nature of the routine calls is dependent on whether the Communication Manager 42 is operating in "command" mode or "data" mode. The Communication Manager 42 operates in command mode when certain telephony operations are being requested, unlike "data" mode which is the case when it is desirable to transfer data from one source to another.

The Communication Manager 42 operates in a continuous main task loop in order to repeatedly process information in the form of a plurality of characters, being transmitted from the communication application 21 into at least one of the plurality of buffers 44a-44n referenced by the communication port driver 41. The main task procedural loop entitled "comMgrTask()" is illustrated at lines 817-900 of the Communication Manager source code entitled "com.sub.-- mgr.c" in Appendix B. The Communication Manager 42 periodically requests the communication port driver 41 to download characters (i.e., pass the pointer referencing the at least one of the plurality of buffers 44a-44n) into one of a plurality of internal buffers 45a-45n, for example a first internal buffer 45a, within the Communication Manager 42, in accordance with processCmdInput() in lines 1216-1293 of the "com.sub.-- mgr.c" source code which makes routine calls to processCmdChars() and doCmdInCopy() pursuant to lines 1419-1448 and 1574-1651 of com.sub.-- mgr.c in Appendix B.

Concurrently, the Communication Manager 42 monitors each downloaded character in an effort to detect an end-of-line ("EOL") character since an AT command is designated as a string of characters preceded by an "ATx" and terminated by the EOL character, such as, for example, a carriage return. (See doCmdInCopy(), lines 1638-1648). If the EOL character is detected, the character string is potentially an AT command. As a result, the Communication Manager 42 transmits the contents of the first internal buffer 45a into the AT Command task 43 in accordance with the sendData() routine on lines 1654-1678 of Appendix B. Thereafter, the Communication Manager 42 asserts a flag 46 within the first internal buffer 45a to prevent writing over its contents until it can be saved in another buffer within the AT Command task 43.

If the present invention is in the "data" mode, the main task loop calls a processData() routine (lines 1142-1158) of the com.sub.-- mgr.c source code to process data (if any) inputted from the communication application and output such data into internal queues to be later processed by unrelated modem code. During such processing, however, the Communication Manager 42 scans the data for a time independent escape sequence in case an AT command is embedded within the data as illustrated in scanData() in lines 1450-1572 of com.sub.-- mgr.c of Appendix B. If the time independent escape sequence is uncovered, the Communication Manager 42 changes states and begins processing the information into its internal registers 45a-45n.

Upon receipt of the contents of the first internal buffer 45a, the AT Command task 43 generates an internal copy of the characters within the first internal buffer 45a and sends it back to the Communication Manager 42, causing the Communication Manager 42 to deassert the flag 46. The AT Command task 43 then does the necessary lexical analysis needed to ascertain the nature of the AT command and thereafter, sends a control command followed by a data string (i.e., collectively referred to as the "control message") into the Daemon application 26. Upon receipt of the control message, the Daemon application 26 reads the control command and logically maps a corresponding TAPI function call to request TAPI services.

Table 1 illustrates logical mapping between the AT command inputted into the AT Command task 43 and the control command outputted from the AT Common task 43 into the Daemon application 26. The number of control commands employed is a designer's choice, and therefore should not be construed as a limitation to the scope of the invention. The source code in Appendix C entitled "mt1hwut1.c" translate ATMx, ATLx and ATHx commands respectively. The marginal notes provide sufficient description of the translation process used by the AT Command task 43 so as to emulate such translations for other AT commands, including ATD and ATA.

Table 2 illustrates logical mapping between the Daemon application 26 and TAPI 29 in the form of function calls. For clarity sake, only the first three control commands listed in Table 1 are shown in view of the fact that a person skilled in the art could deduce additional mapping from the information given.

The source code within Daemon application 26 to perform logical mapping of AT.sub.-- DIAL, AT.sub.-- ANSWER and AT.sub.-- ONHOOK into the corresponding function calls set forth in Table 2 is illustrated in source code entitled "modemdmn.c" "dial.c", "answer.c" and "dispatch.c" in Appendix D. It is contemplated that the source code could be structured in a variety of ways, and therefore the present structure should not be construed as the only structure to perform the present invention.

The operation of the present invention may best be understood by continuing the "dialing request" example previously in reference to FIG. 2. As previously mentioned herein, this specific example lends itself to explaining the operation of the present invention and in no way should be construed as a limitation on the scope of the invention.

The example will focus on a desired operation to dial a local phone number (e.g., 555-5555) in order to connect the computer system to another computer system. In the present example, as prevalent in many business telephone systems, in order to establish a connection with public analog telephone lines when making a local call, a number "9" must be dialed first before the telephone number is dialed.

First, a user would activate the desired communication application which would initialize the present invention and place it in command mode. The user would select a specific operation required from the communication application, which, in this case, is a request to dial a phone. The communication application will then generate a corresponding AT command having the AT command identifier ("ATD") followed by a data string; namely "9, 555-5555". The comma being associated with a specific time delay in order to allow a connection to be established between the computer system and the analog telephone lines after the "9" has been dialed, but before dialing the phone number.

The AT command 22 is sent to the communication port 40 and is sequentially stored a character at a time in one of the plurality of registers 44a or FIFO registers (depending on the ASIC 40 configuration). The Communication Manager 42 retrieves the AT command, along with other information within the register 44a or FIFO and inputs the information into an internal buffer 45a-45n. Upon detecting an End of Line ("EOL") character, the Communication Manager 42 transmits the AT command into the AT Command task 43. The AT Command task 43 then determines that there exists an "ATD" command followed by a dial string and thus, sends a control message (i.e., "AT.sub.-- DIAL 9, 555-5555") to the Daemon application 26.

The above example differs from the operation of the conventional communication scheme in that the conventional communication task reads the AT command 11 sent and generates dialing tones associated with the contents of the data strings in order to perform the requisite dialing. This limits the conventional communication scheme to analog telephone systems. The conventional scheme will not operate with digital PBX systems since AT command set processing is inadequate for advanced telephony environments.

The Daemon application 26 receives the control message from the AT Command task 43. Thereafter, the Daemon application 26 calls a procedure to logically map the control message "AT.sub.-- DIAL 9, 555-5555" into a function call to TAPI with lineMakeCall() incorporating the data string within its parameters. TAPI then drives the I/O board 30 or another board to make the requested phone call.

Since the communication scheme is bi-directional, the TAPI 29 also returns status information concerning a prior TAPI function call through a TAPI result code message, examples of which are shown in Table 3. The Daemon application 26 then logically maps the TAPI result code message into a corresponding status message readable by the AT Command task 43 as shown in Table 4. The status message is input into the AT Command task 43 which analyzes the same to decode the status message into messages readable by the communication application 21.

The following is a detailed description of the operations of the communication Manager and AT Command task which is shown in FIG. 6. In step 100, the computer system is initialized so as to initialize the AT Command task and Communication Manager. After initialization, the computer system is in "command" mode until a connection is established with a remote modem. If the computer system is in "data" mode, it will remain in this mode until the connection is disconnected or upon detection of an escape sequence. Thereafter, the computer system will remain in the "command" mode until the connection is established again through another AT command (e.g., "ATO" for re-establishing a connection after an escape sequence).

Next, steps 101-106 are accomplished by the Communication Manager which is illustrated as operating in the I/O board, but could be operational in the host if a virtual driver is employed in lieu of the communication port. In Step 101, a communication application inputs information into the communication port, or alternatively the virtual driver if chosen. In Step 102, the Communication Manager retrieves the information from the communication port (or virtual driver) and stores the information within a plurality of buffers. However, it is contemplated that the Communication Manager could be designed to retrieve the information upon receipt of an interrupt signal or periodically after a preselected time period. If the later, then such sampling would be necessary before retrieval of the information. Next, the Communication Manager determines whether the computer system is in "command mode" (Step 103) and if so, the Communication Manager processes the information retrieved from the communication port in search of the EOL character (step 104). Otherwise, in step 105, the Communication Manager places the information into internal queues and retrieves more information from the communication port or virtual driver. If the Communication Manager detects an EOL character during such processing, it passes the information (potentially having an AT command) to the AT Command task (step 106).

In step 107, the AT Command task parses the information to determine if the AT command exists, and if so, the nature of the AT command. Next, the AT Command task translates the AT command identifier into a control command readable by the Daemon application (step 108). Next, the AT Command task passes the control command followed by a corresponding data string into the Daemon application in order to request telephony services (step 109). Thereafter, the AT Command task enters into a polling scheme to await status information in the form of a TAPI result code message converted by the Daemon application into an AT Command task status message (step 110). Then, the AT Command task translates the status message into conventional modem result code readable by conventional communication applications (step 111). Thereafter the AT Command task sends the modem result code to the conventional communication application through the Communication Manager and the communication port (or virtual driver).

Furthermore, the operations of the Daemon application is illustrated in FIG. 7 in order to show, among other things, the translation from control message to TAPI function calls. First, the Daemon application is initialized upon initialization of the computer system (Step 200). The Daemon application remains in a polling state awaiting the control message from the AT Command task (Step 201-202). Upon receipt of the control message, the Daemon application translates the control message into an appropriate TAPI function call for operation with TAPI (Step 203) and passes the function call to TAPI (Step 204). In steps 205-206, the Daemon application waits for a result code message by TAPI in response to the function call. Upon receipt of the result code message, the Daemon application translates it into a corresponding status message to be transmitted to the AT Command task which, in effect, processes the status information throughout the computer system (steps 207 and 208). Thereafter, the Daemon application awaits a new control message from the AT Command task (step 209).

The present invention described herein may be designed using many different configurations or slightly different process steps. While the present invention has been described in terms of various embodiments, other embodiments may come to mind to those skilled in the art without departing from the spirit and scope of the present invention. The invention should, therefore, be measured in terms of the claims which follow. ##SPC1##