Two fundamentally different switching technologies exist that enable communications. The first type, circuit-switched networks, operate by establishing a dedicated connection or circuit between two points, similar to public switched telephone networks (PSTN). A telephone call causes a circuit to be established from the originating phone through the local switching office across trunk lines, to a remote switching office and finally to the intended destination telephone. While such circuit is in place, the call is guaranteed a data path for digitized or analog voice signals regardless of other network activity. The second type, packet-switched networks, typically connect computers and establish an asynchronous “virtual” channel between two points. In a packet-switched network, data, such as a voice signal, is divided into small pieces called packets which are then multiplexed onto high capacity connections for transmission. Network hardware delivers packets to specific destinations where the packets are reassembled into the original data set. With packet-switched networks, multiple communications among different computers can proceed concurrently with the network connections shared by different pairs of computers concurrently communicating. Packet-switched networks are, however, sensitive to network capacity. If the network becomes overloaded, there is no guarantee that data will be timely delivered. Despite this drawback, packet-switched networks have become quite popular, particularly as part of the Internet and Intranets, due to their cost effectiveness and performance.
In a packet-switched data network one or more common network protocols hide the technological differences between individual portions of the network, making interconnection between portions of the network independent of the underlying hardware and/or software. A popular network protocol, the Transmission Control Protocol/Internet Protocol (TCP/IP) is utilized by the Internet and Intranets. Intranets are private networks such as Local Area Networks (LANs) and Wide Area Networks (WAN). The TCP/IP protocol utilizes universal addressing as well as a software protocol to map the universal addresses into low level machine addresses. For purposes of this discussion, networks which adhere to the TCP/IP protocol will be referred to hereinafter “IP-based” or as utilizing “IP addresses” or “Internet Protocol address”.
It is desirable for communications originating from an IP-based network to terminate at equipment in a PSTN network, and vice versa, or for calls which originate and terminate on a PSTN network to utilize a packet-switched data network as an interim communication medium. Problems arise, however, when a user on an IP-based or other packet switched data network tries to establish a communication link beyond the perimeter of the network, due to the disparity in addressing techniques among other differences used by the two types of networks.
To address the problems of network disparity, telecommunication gateways have been developed to allow calls originating from an IP-based network to terminate at equipment in a PSTN network, and vice versa, or for calls which originate and terminate on a PSTN network to utilize a packet-switched data network as an interim communication medium. Gateway, such as the NetSpeak Model Nos. WGX-MD/24, a 24-port digital T-1 IP telephony gateway, or WGX-M/16, a 16-port analog IP telephony gateway, both commercially available from NetSpeak Corporation, Boca Raton, Fla., have a plurality of ports through which calls are handled.
Unlike traditional Public Branch Exchanges (PBXs), which merely processed the establishment of a call from one location to another, current telecommunication systems are expected to provide many types of optional services, such as call forwarding, call messaging, call waiting, and data entry, all transparently to the caller. In order to process these various functions, the gateways must be able to process the voice data stream and the call events associated with the call. Call events comprise any action related to a call, e.g. off-hook, on-hook, etc. However, it is desirable for gateway architectures to remain relatively rudimentary, performing only the handling of the data stream. Processing of the call events may be handled by a special server, referred to hereafter as a call flow server. In this manner the telecommunication systems may be updated to handle new types of call events by updating only the call flow server, instead of multiple gateways. Accordingly, gateways forward call events associated with a particular data stream to the call flow server and receive instructions from the call flow server as to how to handle or direct the data stream representing a call.
The call flow server uses algorithms known as “call flows” to handle one or more call events. A call flow typically comprises a series of instructions that control how one or more call events are processed. Such call flows are typically written in state tables, but may also be written in JAVA or any other type of computing language proprietary or not. Call flows are state machine operations that are managed on threads executing on a processor. However, the assignment of call flows to threads can cause problems.
In one technique, all call flow scripts are processed on a single thread. This solution is optimal for a single processor environment. However, this solution is not scalable as additional processing resources are added (i.e. the extra processors are ignored). In addition, a processor intensive call flow will block all other call flows from running (i.e. it is single tasking). In another technique, each call flow script is processed on a separate thread. This technique fully utilizes processor resources on multi-processor machines and ensures that a script is never blocked because another script is running. However, it has the following disadvantages: 1) excessive context switches dramatically degrade performance on single processor machines; 2) a single thread per call flow is not realistic for large call flow environments that may process tens of thousands of calls simultaneously; and 3) call flows cannot be spread among multiple threads since one must ensure that events are received in the order they were sent and this cannot be guaranteed across threads.
Accordingly, there is a need for a method and apparatus that can adjust the call flow load within a single processor or multi-processor environment such that processing of threads associated with the call flows is optimized.
There is a further need for a method and apparatus for a flexible thread manager that has the performance of the single-threaded solution on a single processor system, but which scales intelligently when processors are added.
USPTO Backgrounds
USPTO Backgrounds