Automated and integrated call control server

Allowing a tester of a telephonic device to issue call control commands to a call control server using an intuitive set of commands and using both data lines for data call control commands, and voice lines for touch tone or “DTMF” call control commands. The user may initiate a call control command by either entering the call control command in a command line of a program executed at a telephonic device, or by crafting a function call using an Application Program Interface (API) that allows for more intuitive function calls that are more descriptive of the call control command. During execution, the more descriptive user-entered command or function call is converted into a form that recognized by the call control server. The converted call control command is then transmitted to the call control server.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates to the field of telephone network and device testing. Specifically, the present invention relates to using a call control server to test a telephone network or device in an automated and integrated fashion.

2. Background and Related Art

The telephone has been one of the most pervasive inventions of the modem era. It is now common practice for an individual to use a telephone to audibly converse in real-time with another individual even if the caller and the callee are remotely located. Recently, the types of devices able to support telephonic communication have expanded well beyond what was conventionally thought of as a telephone. For example, digital telephones (hardwired and wireless), and some types of personal computers and Personal Digital Assistants are now able to engage in telephonic communication.

Conventionally, telephonic device manufacturers typically test their telephonic devices prior to distribution to be sure the telephonic device works as intended. In order to ensure the telephonic device works during normal use, it is desirable to test the telephonic device under a wide variety of possible conditions that the telephonic device is anticipated to experience during normal operation. However, normal operation of a telephonic device involves connection and communication with other telephonic devices. Thus, the telephonic device cannot be tested in isolation.

One way to test the operation of a telephonic device and associated telephonic network is to actually have the subject telephonic device communicate in various scenarios with other surrounding telephonic devices, and evaluate the performance of the subject telephonic device and network under the testing scenarios. While the variety of such scenarios are innumerable, such scenarios include, for example, receiving a ring generated by another telephonic device calling in, answering the telephone call and communicating between the devices, engaging in a conference call, or similar common telephonic activities.

According to one conventional method, an individual stations the other surrounding telephonic devices in order to provide the necessary input to those other telephonic devices in order to test the subject telephonic device. However, this requires that a human user take the effort to enter in the correct sequences of input at the correct times in order to provide the desired testing conditions for the subject telephonic device.

In order to remove the cost and unpredictability associated with using humans to station the surrounding telephonic devices, server technology has developed that allows a server to emulate the associated telephone network and surrounding telephonic devices. Servers that have this capability are often called “call control” servers.

Conventional call control servers allow a tester to dial into the call control server and instruct the call control server to perform certain telephone related actions. The instructions may be dispatched by first establishing a telephonic connection with one of the lines of the call control server. Then, the tester may dispatch the instructions by dialing the keypad of a conventional telephone with a particular audible tone sequence. Specifically, when the user enters a digit such as 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, * or # on the keypad, a distinct audible tone is asserted on the telephone connection. The call control server converts the frequency of each successive tone into its corresponding digit 0 through 9, * or #. Specifically, the tones are generated and interpreted using a known standard such as the Dual Tone Multi-Frequency. Then, the call control server may interpret the digits and implement the associated instruction. Thus, a tester may control a conventional call control servers via standard telephone voice lines.

While conventional call control servers are useful in eliminating the need for a person to station surrounding telephones during testing, the number of commands that may be implemented is fairly limited. This is due, in part, to the limited way in which a tester issues commands; namely, through DTMF tones. The dial tone command set associated with a particular call control server is typically not intuitive since the command set is limited to the digits 0 through 9, * and #. Since the command set is not intuitive, it is difficult for a human tester to remember a large number of commands. Accordingly, the amount of scenarios enabled by conventional call control servers is also relatively limited.

Methods also exist for issuing non-audible data commands to call control servers over a data line. However, these conventional methods are limited in the level of integration between the issuing of data commands over data lines, and the actual implementation of such commands on voice lines. For example, under conventional technology, one cannot issue a data command over a data line to command a call control server to establish a multi-line conference call over voice lines.

Therefore, what is desired are mechanisms for telephonic testing in which the call control server has more integrated data and voice features, and in which the tester may use a more intuitive command set thereby allowing for more testing scenarios.

SUMMARY OF THE INVENTION

Methods, systems and computer program products are described for allowing a tester to issue call control commands to a call control server using an intuitive set of commands and using both data lines for data call control commands, and voice lines for touch tone or “DTMF” commands.

The user may initiate a call control command by either entering the call control command in a command line of a program executed at a telephonic device, or by crafting a function call using an Application Program Interface (API) that allows for more intuitive function calls that are more descriptive of the call control command. During execution, the more descriptive user-entered command or the function call is converted into a form that is recognized by the call control server. The converted call control command is then transmitted to the call control server.

Many call control servers are configured to respond to commands in which the characters of the command are limited to the digits 0 through 9, “*”, and “#” corresponding to the keypad of a conventional telephone. However, such commands are typically not descriptive of the actual call control command. For example, the sequence “001*” could mean “hang up immediately.” However, a casual observer would not be able to tell what the sequence means without memorizing the meaning. One the other hand, a function call or command CCSMakeConf ccsLine1ccsLine2is more intuitive and descriptive. This command instructs the call control server or CCS to make a conference call (MakeConf) using two identified lines (e.g., ccsLine1and ccsLine2). Since the principles of the present invention allow for more descriptive and user-friendly call control commands, the set of call control commands is less confusing, and thus the user may master more call control command thereby making more effective use of the call control server.

In addition to the flexibility in how the user may issue call control commands, the call control server also allows testers to issue commands over both data and voice lines. Thus, a tester may issue a command over a data line to engage two voice lines in a teleconference.

DETAILED DESCRIPTION OF THE INVENTION

The present invention extends to methods, systems, and computer program products for allowing a tester to issue call control commands to a call control server in order to test a network of telephonic devices. The tester has flexible and wide ranging control over the scenarios that may be tested. Specifically, the tester may issue commands and have actions taken on various voice lines using a more flexible and robust data connection, rather than having to rely exclusively on entering commands via a voice line using tone signals. Also, the tester has available a more intuitive set of commands that may be entered in a command line, or may be passed through an Application Program Interface (API), for translation into commands that are recognized by the call control server.

When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.

FIG. 1illustrates an example telephonic environment100having a telephonic device101that one might desire to test for performance. The telephonic environment100includes a number of telephonic devices101,102,103,104and105communicating over a network106. Although the telephonic devices are illustrates as being conventional telephones, the telephonic devices may include any devices (wired or wireless) that are capable of communicating via a telephone connection. The telephonic device101is shown slightly larger to identify it as the test subject. The remaining telephonic devices102,103,104and105might be other telephonic devices that the subject telephonic device101might communicate with in normal operation

Typically, there are two kinds of connections possible between telephonic devices, voice and data. Traditionally, telephonic devices were used just for communicating voice information. Such telephonic devices used a voice line to establish a voice connection over circuit-committed protocols of the Public Switched Telephone Network (PSTN). Many more recent telephonic devices may use a data line to establish a data connection for communicating data over a network. For example, Internet Protocol (IP) based networks are suitable for conveying data at a fairly low error rate.

Referring back to the example telephonic environment100ofFIG. 1, voice lines are representing using solid lines connected to the network106, and data lines are represented using dashed lines connected to the network106. The subject telephonic device101has three voice lines101v1,101v2and101v3and one data line101d. The telephonic device102also has both a voice line102vand a data line102d. Telephonic devices103and104have only a voice line103vand104v, respectively. Telephonic device105has only a data line105d. Although the network105is illustrated generically, it will be apparent that PSTN networks may be used to establish voice connections. In addition, PSTN networks or Public Land Mobile Networks (PLMN) may be used to establish data connections.

During normal operation, the telephonic device101may engage in a two-way voice call with any one of telephonic devices102,103or104. In addition, the telephonic device101may engage in a conference call with two or all of telephonic devices102,103or104. Furthermore, the telephonic device101may upload a file to, or download a file from, one or more of the telephonic devices. A tester will often try to simulate normal operations that the telephonic device is expected to encounter. Since having an individual station each of the telephonic devices for testing can be expensive, call control servers are often used to test the performance of a subject telephonic device.

FIG. 2schematically illustrates a subject telephonic device in communication with a call control server so as to emulate the environment illustrated in FIG.1. Here, instead of communicating with telephonic devices102,103,104and105, the various telephonic functions of the subject telephonic device101are tested by communicating instead with the call control server201.

For example, in order to test the capability of the subject telephonic device101to receive a telephone call, the call control server201may place a telephone call to the subject telephonic device. In order to test the capability for placing a telephone call, the subject telephonic device101may call the call control server201. In order to test the integrity of a voice connection, the call control server may render audio information on the voice connection. Alternatively or in addition, the subject telephonic device101may render audio information on the voice connection. In order to test the integrity of a data connection, the subject telephonic device101and the call control server201may exchange data files. Also in order to test the ability to engage in a conference call, the call control server may connect the first voice line established between the subject telephonic device101and the call control server201with a second voice line. The call control server may then render audio information on the second voice line. The rendered audio information may then be measured on the subject telephonic device to determine the integrity of the conference call defined by the first and second voice connections. Although the instructions to the call control server201may be issued by the telephonic device101that is subject to testing, the instructions may also originate from another telephonic device such as telephonic device202. Note that the telephonic devices101and202may communicated with the call control server201using voice lines represented by solid lines, and data lines represented by dashed lines.

With reference toFIG. 3, an example system for implementing the call control server201includes a general purpose computing device in the form of a conventional computer320, including a processing unit321, a system memory322, and a system bus323that couples various system components including the system memory322to the processing unit321. The system bus323may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)324and random access memory (RAM)325. A basic input/output system (BIOS)326, containing the basic routines that help transfer information between elements within the computer320, such as during start-up, may be stored in ROM324.

The computer320may also include a magnetic hard disk drive327for reading from and writing to a magnetic hard disk339, a magnetic disk drive328for reading from or writing to a removable magnetic disk329, and an optical disk drive330for reading from or writing to removable optical disk331such as a CD-ROM or other optical media. The magnetic hard disk drive327, magnetic disk drive328, and optical disk drive330are connected to the system bus323by a hard disk drive interface332, a magnetic disk drive-interface333, and an optical drive interface334, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules and other data for the computer320. Although the exemplary environment described herein employs a magnetic hard disk339, a removable magnetic disk329and a removable optical disk331, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like.

Program code means comprising one or more program modules may be stored on the hard disk339, magnetic disk329, optical disk331, ROM324or RAM325, including an operating system335, one or more application programs336, other program modules337, and program data338. A user may enter commands and information into the computer320through keyboard340, pointing device342, or other input devices (not shown), such as a microphone, joy stick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit321through a serial port interface346coupled to system bus323. Alternatively, the input devices may be connected by other interfaces, such as a parallel port, a game port or a universal serial bus (USB). A monitor347or another display device is also connected to system bus323via an interface, such as video adapter348. In addition to the monitor, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

The environment illustrated inFIG. 3may be used to implement a call control server that responds to various call control commands, whether those commands be issued in the form of voice or touch tone DTMF commands over a voice line, or whether those commands be issued in the form of other data over a data line.FIG. 4illustrates a more detailed architecture400that may be implemented by the environment described with reference to FIG.3.

The architecture400includes a modem401that is capable of connecting to one or more data lines402via, for example, a COM port. In the illustrated example, the modem401is capable of connecting to four data lines402a,402b,402cand402d. The design of the modem401is not critical to the present invention. The modem401may be, for example, any modem capable of establishing a connection with one or more data lines, receiving data over the connection, and then passing the received data to other components for further processing. The modem401may also be capable of transmitting data over the one or more data lines.

The call control server201is also capable of receiving voice or DTMF commands over one or more voice lines403including, for example, voice lines403a,403b,403cand403d. A voice board404is capable of receiving the voice or DTMF commands and passing such commands up to other components for further processing. The voice board404may also be capable of rendering digital audio files (e.g., “WAV” files) on the one of more voice lines403. Any modem capable of connecting to a data line may be used in the environment illustrated.

Any call control commands received via the data lines402are then passed from the modem401to a Telephony Application Program Interface (TAPI) Service Provider405. Also, any call control command received via the voice lines403are passed from the voice board402to the TAPI service provider405. The TAPI service provider405may be, for example, a pluggable software module authored and provided by a commercial telephone carrier. Such pluggable software modules are conventionally available.

The TAPI Service Provider405then passes the commands to a Telephony Application Program Interface (TAPI) module406. As well known to those of ordinary skill in the art, a TAPI module406provides a set of interfaces to telephone application developers. Telephony software application may make function calls to the TAPI module406by specifying the function call with a predefined structure defined by TAPI. The services provided by the TAPI module406are published along with the prescribed structure of the corresponding function calls. For example, the TAPI interfaces may be used to detect that a call is received on a given line, instruct to answer the call, hang up, detect that the other party has hung up, detect that a DTMF tone is being received, instruct to provide the corresponding DTMF sequence when a terminating character (e.g., star “*”) is detected, connect two lines in a conference call, and the like. The TAPI module406serializes any received information such that application programs do not need to deal with receiving multiple streams of information in parallel.

The telephony application components that make such TAPI function calls include a command interpreter407and an action scheduler408. In the event that a DTMF call control command was received over one of the voice lines403, the TAPI module406will provide the DTMF sequence to the command interpreter407. The command interpreter407may have previously given the TAPI module406an instruction to pass it any received DTMF sequence once the tone corresponding to the star symbol “*” is detected. The DTMF sequence received by the command interpreter407is not the original DTMF tones received by the voice board404, but rather is the corresponding DTMF sequence represented by the letters 0 through 9, the star symbol “*”, or the number symbol “#”. The user of the telephonic device101may have generated this DTMF sequence by dialing the sequence on a keypad.

The command interpreter407may also receive call control commands in data form from one or more data lines402. The TAPI module406passes these data commands to the command interpreter407. Thus, the command interpreter407may receive call control commands that were received over voice lines403, as well as data lines402. This provides the call control server with a high level of flexibility in what call control functions may be invoked, and how they are invoked.

The command interpreter407breaks down the call control command into specific actions necessary to fulfill the call control command. These actions are then passed to the action scheduler408, which schedules the actions according to the priority of the action. For example, a time sensitive action such as calling someone in a one second window of availability would require an immediate response. The higher priority actions will be placed in a queue409for immediate implementation, while the lower priority actions may be placed in a database410. If the queue409or the action scheduler408is idle, the action scheduler408may scan the database410for actions to perform.

FIG. 5illustrates a flowchart of a method500for allowing call control in a flexible manner using data commands. The call control server first receives a call control command (act501). For example, the call control server may receive a DTMF command over the voice lines403, or perhaps receive a data call control command over the data lines402. In response to the call control command, the call control server performs a step for processing so as to fulfill the call control command one on or more voice lines (step502). In one embodiment, this includes specific corresponding acts503.504and505.

In particular, the call control server interprets the call control command (act503). This may be accomplished by, for example, the command interpreter407interpreting the call control commands as they are received from the TAPI module406. The call control server then determines one or more acts that would need to be accomplished to comply with the call control command (act504). This may also be accomplished by the command interpreter407. The call control server then implements the one or more acts on one or more voice lines (act505). This may be accomplished by, for example, the command interpreter407providing an identification of the acts to the action scheduler408. Then, the action scheduler, schedules the actions, and then implements the actions at the appropriate time by providing one or more function calls to the TAPI module406.

FIG. 6illustrates a suitable hardware structure and software architecture of a telephonic device600in which the principles of the present invention may operate. The telephonic device remotely operates the call control server201of FIG.2and may be, for example, the telephonic device101that is subject to testing, or perhaps another telephonic device (e.g., telephonic device202) that may be connected to the call control server.

The telephonic device600includes a user interface601for allowing a user to make a connection to a network. The user interface601includes a microphone606for rendering audio information into electronic form. In addition, dialing controls607include12buttons through which a user may enter information. For example, a user may dial a telephone number or enter touch-tone instructions for the call control server201via the dialing controls607

Although the user interface601has the appearance of a mobile telephone, the unseen features of the user interface601may allow for complex and flexible general-purpose processing capabilities. For example, the telephonic device600also includes a processor611and a memory612that are connected to each other and to the user interface601via a bus610. The memory612generically represents a wide variety of volatile and/or non-volatile memories that may be employed. The particular type of memory used in the telephonic device600is not important to the present invention.

Program code means comprising one or more program modules may be stored in memory612. The one of more program modules may include an operating system613, one or more application programs614, other program modules615, and program data616.

FIG. 7illustrates a flowchart of method700of using an Application Program Interface (API) in accordance with the present invention for providing a more intuitive command set to the tester of the telephonic device. An application program interface (API) is the specific method prescribed by a computer operating system or by an application program by which a programmer writing an application program can make requests of the operating system or another application. For example, referring toFIG. 8, an application program801may include one or more function calls802which, when executed, are recognized as requests for service by another program such as operating system803. The application program interface804provides a set of prescribed methods and structures for making the function call in such a manner that the other program may interpret the function call.

Referring toFIG. 7, some of the acts performed in the method700are performed by the calling application (e.g., the application program801of FIG.8). These acts are listed in the left column ofFIG. 7under the heading Calling Application. Other acts are performed by the application or operating system that receives the function call (e.g., the operating system803of FIG.7). These acts are listed in the right column ofFIG. 7under the heading Receiving Application.

First, the calling application performs a specific act of generating a function call that represents a request for the call control server to emulate a telephonic scenario (act701). The request may be in a form that is not recognized by the call control server. Specific examples of source code that may generate a function call are described below with respect to FIG.9.

Next, the calling application passes the function call to a set of one or more program modules for translation of the request into a form that is recognized by the call control server (act702). In the example ofFIG. 8, the function call802is passed to the operating system804. However, if the receiving application is executed in a different machine than the calling application, the calling application may pass the function call in the form of a Remote Procedure Call (RPC).

The receiving application then receives the function call (act703). In response, the receiving application translates the request into a form that is recognized by the call control server (act704) and then sends the translated request to the call control server (act705). Thus, the developer of the calling application may generate function calls that represent call control commands in a manner that is more intuitive to the programmer. Although these call control server may not recognized the more intuitive call control commands, the receiving application translates the call control command into a form that, although it may have a less intuitive form, is at least recognized by the call control server.

Since the programmer has available a more intuitive set of function calls from which to choose, the programmer is able to more easily work with larger permutations of call control commands as compared to having to work with less intuitive call control commands that are directly recognized by the call control server.

For example, in order to make a call control command function call, the calling application present in the telephonic device600may use a TAPI module to issue a command to the call control server201. Upon connection with the call control server201, the TAPI module may then return a handle that the calling application may use when making function calls. The use of a handle in one aspect of the invention will be described below with respect to the various Application Program Interface (API) function calls illustrated in FIG.9.

FIG. 9illustrates a series of APIs that function calls may follow to implement the principles of the present invention.FIG. 10illustrates a data structure1000called CCCParam, which represents various parameters related to a call control command. For example, the CCCParam data structure may include a field1002that usually describes an interval of time for an action, a field1003that usually describes a period of time that represents the life span of the action from the time the action starts, and a field1004that usually represents user information such as a telephone number. The data structure1000also includes a field1001that represents a mask indicating which of the fields1002,1003, and1004are valid.

For example, the data structure1000may be defined in C++ as follows:

{DWORD//mask to tell API which of the following datadwmask;//members are valid://INTERVAL_VAL(0x01) = dwInterval is valid//PERIOD_VAL(0x02) = dwPeriod is valid//USRDATA_VAL(0x04) = szUsrData is validDWORD//action intervaldwInterval;DWORD//action life span period from the time an actiondwPeriod;//startsTCHAR//user information such as telephone numberszUsrData[32];}

Referring back toFIG. 9, the uppermost API900A represents an API structure that function calls may follow to request to stay connected for a period of time. The API900A is listed as BOOL CCCStayConnected(HCALL hcall, CCCParam&cccParam). The “hcall” parameter is the handle returned by the TAPI module upon connection with the call control server201. The &cccParam parameter represents an instance of the type CCCParam described above with reference to FIG.10. When using this API900A, only the dwInterval member of the CCCParam data structure is used. The dwInterval member is used to specify the amount of time, in seconds, that the call control server201should remain connected before hanging up.

The second API900B represents a structure that functions calls may follow to request that the call control server call back to a specified telephone number. For this API, all of the members of the CCCParam must be valid (i.e., the mask field1001should be set to 0×07). Here, the szUsrData member includes the telephone number that the call control server should call back to. The call control server201will call back to that number every “dwInterval” seconds for a period of “dwPeriod”.

The third API900C represents a request for the call control server to echo data supplied from the telephonic device600back to the telephonic device600. In this case, szUsrData contains the data that the tester wishes to echo. dwPeriod is the number of times the call control server201should echo the data (not the minutes the echo shall last). If the tester wishes different data to be echoed, the same API is used but with a similar function call that has the different echo data specified in the szUsrData member. Note that echoing data is performed with data lines. To accomplish the echo feature, the telephonic device uses a TAPI module to establish a data connection with the call control server and, in response, receives the handle over the data line.

The API900D may be used to request that data be downloaded from the call control server201. The parameter szFileName is used to specify the name of the file to be downloaded.

The API900E adds a client telephonic device to the call control server's telephone list. Both the dwPeriod and szUsrData members of the data structure cccParam must be valid. The dwPeriod member tells the call control server how long it should keep the telephone device's information. The szUsrData member indicates the telephonic device's telephone number. The ActionInterest is a data type that allows for enumeration of various desired actions. The actMask variable may be used to discern actions or interest from actions of no interest using a binary mask.

These APIs900A through900E illustrates examples of how function calls may be made to another application program through a TAPI module. The receiving application program may convert these function calls into less intuitive forms recognized by the call control server201before transmitting the call control command to the call control server.

Instead of having to draft a program that includes these types of function calls, a user may instead type in a simply command that results in execution of a program that makes the function calls. For example, a user may type in the following call control command in a command line:

This command is translated into an instruction to the call control server to establish a conference call between the client and two call control server lines.

Also the command “CCSCallBack myNumber” may be used to instruct the call control server201to call the specified number.

These various APIs and command are expressed in language that is relatively intuitive to a human programmer or user. However, the APIs and commands may not be recognized by the call control server201. Accordingly, the receiving application translates these commands into a potentially less intuitive form that is recognized by the call control server.

For example, as mentioned above, a user may enter a sequence of DTMF tones representative of the keypad characters 0 through 9, star “*”, and number “#”. These DTMF sequences may be recognized by the call control server even though the DTMF sequences are not necessarily intuitive. For example, the less intuitive DTMF commands may include “001*” which means to hang up immediately, “002*X*” which means to stay connected for X seconds, “003#X#Y#A*” which means to call me back at the number X every Y seconds for Z minutes, or “004#X#Y*” which means to put my address X on the call control server's telephone list for Y minutes during which the call control server201may do something to the telephone number according to my interest Y (e.g., conference, voice call, data call, or the like). These command are not intuitive in that they do not resemble anything descriptive in any human language.

The user may also enter non-DTMF data call control commands such as “echo#X#Y*” which means to echo data X back for Y times, or perhaps “download#X*” which means to download file X to me.

By allowing for translation of more intuitive commands into the command forms recognized by the call control server, there is increased flexibility on how a user may issue a call control command. In addition, there are additional, more intuitive ways for a user to issue the call control commands. Thus, the user may have an easier time working with the call control commands. In addition, as mentioned above, the user may issue commands over a data line as well, instead of being limited to issuing commands using a sequence of just 12 DTMF tones. Accordingly, the principles of the present invention provide for systems, methods and computer program products for allowing for more flexible and intuitive testing of a telephonic device.