Abstract:
A system and method for Enhanced Overflow Call Processing redirects calls which cannot be completed to alternate terminations. An originating switch queries a network database for an alternate termination for the call each time the originating switch detects that the call cannot be completed to the current termination. The network database determines the alternate termination for each query using a hierarchical set of multi-branch overflow statements which are configured by the user. A set of overflow statements is selected by the network database based on the original termination of the call. The set of overflow statements is searched hierarchically until an active overflow statement is found. This overflow statement then controls all queries relating to that call. The reason the call was not completed is used to select either an alternate termination to which the call is to be routed or a particular treatment, such as a busy signal or network message, which is to be applied to the call. If an alternate termination is selected, the originating switch routes the call to the alternate termination. The process then repeats until either the call is completed, the overflow statement specifies a treatment is to be applied, or a predetermined number of completion attempts to alternate terminations have occurred.

Description:
CROSS-REFERENCES TO RELATED APPLICATION 
     This is a continuation-in-part of patent application Ser. No. 08/370,428, filed Jan. 9, 1995 now abandoned. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to routing a telephone call to an alternate termination when the call cannot be completed to an originally selected termination. 
     2. Background Information 
     Many businesses desire that calls which cannot be completed to their intended terminations be rerouted to a secondary or alternate termination. Calls may fail to complete for a variety of reasons. For example, the intended termination may refuse the call or may be unable to accept it. A customer dialing an 800 number might initially be routed to an understaffed call center. Rather than have the customer receive a poor grade of service, such as an unacceptably long wait, the call center manager may prefer to redirect the call to a secondary termination which may be able to provide a higher grade of service. 
     A typical prior art telephone network  100 , which provides call redirection, is shown in FIG. 1, as having three network switches  102 ,  104  and  106  are connected by trunks  122 ,  124  and  126 . Each switch  102 ,  104  and  106  may also be connected to one or more local exchange networks (LEN) and/or one or more customer premise equipment (CPE), represented by blocks  110 ,  112  and  114 , respectively. Each LEN/CPE is connected to one or more terminations, such as standard telephones or private branch exchanges (PBX), represented by blocks  111 ,  113  and  115 , respectively. Each switch is also communicatively coupled to at least one network database  108  over signaling network  128 . 
     Network  100  is exemplified by U.S. Pat. No. 5,369,695 to Chakravarti et al. In Chakravarti et al., a telephone network switch  102  is arranged so that after forwarding an incoming call from LEN/CPE  110  to an intended terminating switch  104 , switch  102  responds to any one of a number of conditions requiring redirection of the call by redirecting the call to an alternate termination, switch  106 , identified as a function of a redirect code derived from associated calling information. Such conditions include the case of ring no answer and the case in which an answering party requests such redirection. The switch obtains the redirection code from a centralized network database  108  which derives the redirection code from calling information supplied by the switch. 
     Chakravarti et al. describes call redirection in response to three conditions: ring no answer, busy and post ringing redirection request. However, call redirection may be desired in response to any condition which prevents call completion. Examples of such conditions are: network congestion, transmission line outage, switch failure and LEN or CPE inability to complete the call. Chakravarti et al. does not deal with these conditions. In addition, Chakravarti et al. describes performing the same call redirection in response to all three conditions. It is desirable to vary the redirection performed depending upon the condition encountered. 
     Another typical prior art redirection scheme is described in U.S. Pat. No. 5,253,288 to Frey et al. In Frey et al., a call from originator  111  is initially extended through a toll network  100  toward the first destination  113 ; if the toll network  100  is congested and cannot reach an egress switch  104  to access the first destination  113  or if a local exchange network  112  connecting the first destination  113  to the toll network  100  is congested, or if a first destination PBX  113  cannot be reached from the toll or local network because all access channels thereto are blocked, or if the first destination PBX  113  is congested or attendants are unavailable, an indication that the call cannot be completed to the first destination  113  is sent back to the ingress switch  102  of the toll network for that call. The call is then redirected from the ingress switch  102  of the toll network to an alternate destination  115 . If the first choice destination  113  is a PBX and the PBX rejects a call, the reason for the rejection can be used for altering the choice of an alternate destination or for canceling a potential redirection. 
     Frey et al., describes redirection of calls using tables organized around “non-existent” switch numbers. When a call having an indication that it is to be directed to a non-existent switch enters a switch, the non-existent switch number is translated within the switch to provide the real number of the destination switch. Frey et al., describes providing multiple alternative destinations by using tables to store a plurality of destination entries and incrementing from one table entry to the next. Frey et al. also describes altering the choice of an alternate destination based on the reason a call was rejected, but does not describe a mechanism for accomplishing this. The method described in Frey et al. provides limited flexibility for call redirection. 
     A need exists for improved control over multiple redirection of calls to upgrade the quality of service currently available to businesses and subscribers. 
     SUMMARY OF THE INVENTION 
     The system and method for enhanced call redirection provides call redirection of a call from one termination to at least one alternate termination in response to the failure of a call to be completed. In addition, it provides a hierarchical, user-configurable capability to redirect calls differently depending upon the reason the call was not completed. 
     In operation, a call enters a telephone network through an originating switch. The originating switch queries a network database to obtain routing information needed to route the call. Using this routing information, the originating switch routes the call to a terminating switch which attempts to complete the call to a currently selected termination. The originating switch then determines whether the call was completed to the currently selected termination. If the call was not completed, the originating switch releases the call from the terminating switch and queries the network database for a second termination for the call. The originating switch then routes the call to a terminating switch coupled to the second termination. 
     The originating switch queries a network database for an alternate termination for the call each time the originating switch detects that the call cannot be completed to the current termination. The network database determines the alternate termination for each query based on information regarding the reason the call was not completed. This information is supplied by the originating switch in the query message. The determination is controlled by a hierarchical set of multi-branch overflow statements which are configured by the user. 
     A set of overflow statements is selected by the network database based on the original termination of the call. The set of overflow statements is searched hierarchically until an active overflow statement is found. This overflow statement then controls all queries relating to that call. The reason the call was not completed is used to select either an alternate termination to which the call is to be routed or a particular treatment, such as a busy signal or network message, which is to be applied to the call. If an alternate termination is selected, the originating switch routes the call to the alternate termination. The process then repeats until either the call is completed, the overflow statement specifies a treatment is to be applied, or a predetermined number of completion attempts to alternate terminations have occurred. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a typical prior art telephone network  100  which provides call redirection. 
     FIG. 2 a  is an exemplary block diagram of a telephone network  200 , in accordance with the present invention. 
     FIG. 2 b  is an exemplary block diagram of a switch  212 ,  214  or  216 , shown in FIG. 2 a.    
     FIG. 2 c  is an exemplary block diagram of a network database  208 , shown in FIG. 2 a.    
     FIG. 3 is a state diagram of the operation of network  200  of FIG. 2 a.    
     FIG. 4 a  is an example of a basic overflow statement  400   a  used to specify overflow routing. 
     FIG. 4 b  is an example of two overflow statements combined to form an overflow branch statement  400   b.    
     FIG. 4 c  is an example of an overflow sequence  400   c , which loops back upon itself and also contains a multiple condition. 
     FIG. 4 d  is an example of a multiple branch overflow tree. 
     FIG. 4 e  is an example of one overflow tree linked to a second overflow tree. 
     FIG. 4 f  shows three levels of overflow tree hierarchy: 
     FIG. 5 a  is a flow diagram of a call redirection process  500 , implemented in network  200  of FIG. 2 a.    
     FIG. 5 b  is a flow diagram of a subprocess of step  522  of process  500 . 
     FIG. 6 is a chart of ISDN call values. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 2 a  is an exemplary block diagram of a telephone network  200 , in accordance with the present invention. Network  200  includes a plurality of telecommunications switches  212   a-n ,  214  and  216   a-n . For purposes of this explanation, particular switches are designated originating or terminating switches based on the function they perform in this example. Switches  212   a-n  are designated originating switches because they represent the switches through which an exemplary call enters network  200 . Switches  214  and  216   a-n  are designated terminating switches because they represent the switches through which the call exits network  200 . However, all switches shown are essentially similar and typically perform both functions simultaneously in actual operation. 
     A call is placed from origination  202  to termination  224 . As shown in FIG. 2 a , each station  202 ,  224 ,  226  and  228  connects to network  200  through a telephone system  204 ,  218 ,  220  and  222  respectively. Each telephone system  204 ,  218 ,  220  and  222  may be, for example, an international telephone system, an automatic call distributor, a local exchange network, a customer premise equipment, or a subtend. 
     Desired terminating switch  214  is coupled to desired termination  224  through telephone system  218 . Switch  214  is designated “desired” to indicate that it is the originally intended terminating switch for the call. Each overflow terminating switch is coupled to an overflow termination  226  or  228  through telephone systems  220  or  222 , respectively. Switches  216   a-n  are designated “overflow” to indicate that they are subsequent terminating switches of the call. For any particular call, there is only one desired terminating switch, but in actual operation, each switch typically is the desired terminating switch for some calls and the overflow terminating switch for other calls. In addition, the same switch may serve as both the desired and the actual terminating switch for the same call with respect to different customer terminations connected to that switch. 
     Signaling network  210  communicatively couples each switch and a network database, known as a network database  208 . Signaling network  210  is a standard signaling network, such as, for example, ANSI SS 7 , ITU CCS 7  or X. 25 . Network processor  240  is also communicatively coupled over signaling trunks  230  to all switches in network  200 . 
     Each originating switch  212   a-n  is coupled through trunks  230  to desired terminating switch  214  and overflow terminating switches  216   a-n . Trunks  230  represent a portion of the entire network  200  and may contain a number of trunks and switches. Calls are routed from originating switches to terminating switches over trunks  230 . Calls may be routed directly from the originating switch to the terminating switch or they may be routed through one or more intermediate switches. Each originating switch  212   a-n  contains information identifying the other switches to which it is directly connected. If desired terminating switch  214  is directly connected, the originating switch will route the call directly to desired terminating switch  214 . If desired terminating switch  214  is not directly connected, or if the originating switch detects that the call cannot be routed to desired terminating switch  214 , network processor  240  recommends a routing through an intermediate switch. Network processor  240  sends a message containing the routing recommendation to the originating switch over signaling network  210 , whereupon the originating switch routes the call according to the recommendation. 
     FIG. 2 b  is an exemplary block diagram of a switch  212 ,  214  or  216 , shown in FIG. 2 a . Switch  212  includes audio trunk interface  212 - 14  which connects switch  212  to trunks  206  and  230 . Switching matrix  212 - 13  is connected to interface  212 - 14  and provides cross-connect switching between audio circuits. Processor interface  212 - 12  connects switching matrix  212 - 13  to local area network  212 - 15  and allows switch control processor  212 - 1 , which also connects to network  212 - 15 , to control and interrogate switching matrix  212 - 13 . Also connected to network  212 - 15  is signaling interface  212 - 16  which connects switch  212  to signaling network  210 . 
     Although only one switch control processor  212 - 1  is shown in FIG. 2 b , it is well known in the art that switch functionality may be distributed among several intercommunicating processors. Such processors may communicate over LAN  212 - 15  or over other well known communication paths. Switch control processor  212 - 1  includes several elements. CPU  212 - 2  executes program instructions and processes data. Memory  212 - 6  stores program instructions executed by and data processed by CPU  212 - 2 . Mass storage  212 - 3  stores data to be transferred to and from memory. Mass storage includes such devices as, for example, hard disk drives, floppy disk drives, removable disk drives, magneto-optic drives, optical drives and tape drives. Network interface  212 - 4  communicates with other devices and transfers data in and out of switch control processor  212 - 1  over local or wide area networks, such as, for example, Ethernet or Token Ring. All these elements are interconnected by bus  212 - 5 , which allows data to be intercommunicated between the elements. 
     Memory  212 - 6  is accessible by CPU  212 - 2  over bus  212 - 5  and includes data partition  212 - 10 , call processing routines  212 - 7  and operating system  212 - 8 . Call processing routines  212 - 7  implement the portions of process  500  of FIG. 5 a  (to be described hereinafter) which are performed by the originating switch  212  and the terminating switches  214  and  216 . Data partition  212 - 10  includes a plurality of call entries  212 - 11 - 1  to n, each entry corresponding to a call being routed by the switch. Each entry contains an indicator  212 - 11 - 1 - 1  to  212 - 11 -n- 1  of the call being processed. Each entry also contains an indicator  212 - 11 - 1 - 2  to  212 - 11 -n- 2  of the current termination to which the call is to be or has been routed and an indicator  212 - 11 - 1 - 3  to  212 - 11 -n- 3  of the condition or conditions encountered that caused the call completion attempt to fail. These indicators are used, as described hereinafter, to query network database  208  for alternate terminations. 
     FIG. 2 c  is an exemplary block diagram of a network database  208 . Although only one network database  208  is shown in FIG. 2 a , it is well known in the art that a distributed architecture in which more than one system performs each function is entirely equivalent. Network database  208  includes several elements. CPU  208 - 1  executes program instructions and processes data. Memory  2084  stores program instructions executed by and data processed by CPU  208 - 1 . Mass storage  208 - 5 , stores data to be transferred to and from memory. Mass storage includes such devices as, for example, hard disk drives, floppy disk drives., removable disk drives, magneto-optic drives, optical drives and tape drives. Signaling interface  208 - 2  communicates with other devices and transfers data in and out of the computer system over signaling network  210 . Network database  208  may also include an operator interface  208 - 3 , which provides status information to and accepts commands from a system operator. All these elements area interconnected by bus  208 - 6 , which allows data to be intercommunicated between the elements. 
     Memory  2084  is accessible by CPU  208 - 1  over bus  208 - 6  and includes operating system  208 - 9 , program partition  208 - 7  and data partition  208 - 8 . Program partition  208 - 7  stores and allows execution by CPU  208 - 1  of program instructions which implement the portions of process  500  of FIG. 5 a  infra. which are performed by the network database. Data partition  208 - 8  is accessible by CPU  208 - 1  and stores data used during the execution of program instructions, such as, for example, overflow trees sets  208 - 8 -a through n. The structure of the overflow tree sets is described below. 
     FIG. 3 is an example of the operation of network  200 , in accordance with the present invention. It is best viewed in conjunction with FIG. 2 a . When a call is placed from origination  202  to termination  224 , the call is connected through telephone system  204 . The call enters network  200  through one of tie originating switches  212   a-n , for example, through switch  212   a . If the call is a special service call, such as a call to an  800 ,  900  or virtual network (VNET) number, switch  212   a  sends an initial routing request to network database  208  over signaling network  210 . Network database  208  returns a routing response containing a translated number. The translated number is a geographic telephone number for termination  224  with which switch  212   a  can route the call. Originating switch  212   a  routes the call to desired terminating switch  214 , which attempts to complete the call through telephone system  218  to termination  224 . 
     If the call cannot be completed, originating switch  212   a  detects that condition, either by expiration of a timer, in the case of ring no answer, or by receiving a signaling message from terminating switch  214 , in all other cases. In all cases, originating switch  212   a  then releases the call to terminating switch  214 . Originating switch  212   a  then sends network database  208  an overflow request over signaling network  210  requesting an alternate termination for the call. The overflow request includes the dialed telephone number and an indicator of the cause of the call completion failure. Network database  208  accesses the overflow trees for that called number and determines the response specified by the appropriate overflow tree, based on the indicated cause. Network database  208  then sends a routing response to switch  212   a  containing an indication of the alternate termination. Originating switch  212   a  then routes the call to the alternate termination through an overflow terminating switch. For example, the call may be routed to station  226  through overflow terminating switch  216   a . The terminating switch which is currently attempting to complete the call is the current terminating switch. 
     If the call to station  226  cannot be completed, originating switch  212   a  again detects this condition, releases the call from overflow terminating switch  216   a  and sends another overflow request to network database  208 . This process repeats until the call is completed or until a predetermined number of completions have been attempted. For any given call, network database  208  keeps track of the number of completion attempts and terminates the process when a predetermined number has been exceeded. 
     A signaling message is generated by the current terminating switch when it detects that the call cannot be completed to the current destination. The signaling message is transmitted from the current terminating switch to originating switch  212   a  over signaling network  210 . Signaling network  210  is a separate network from trunks  230 . Even if the call has been routed through an intermediate switch, the signaling message from the current terminating switch is not handled by the intermediate switch. Thus, originating switch  212   a  always receives the signaling message from the current terminating switch, never from any intermediate switch. 
     FIG. 4 a  is a flow diagram of a basic overflow statement  400   a  used to specify overflow routing. Statement  400   a  includes three components. I n    402   a  is the intended termination of the call, C n    404   a  is the condition encountered and O n    406   a  is the object of the statement. 
     The intended termination of the call is the service location to which the call was originally intended to be completed on the original call completion attempt. The intended termination is also the previous intended termination for all overflow completion attempts. The intended service location may be any of several termination types, such as, for example, seven-digit digital trunk controller (DTC) dedicated access lines (DAL), ten-digit DTC DALs, flexible DTC DALs, switched terminations through a local exchange network and outbound international virtual network connections. 
     The condition encountered is the condition at the intended service location on which overflow action is to be taken. In general, there are four conditions. 
     1. Busy—a busy condition is defined as an All Trunks Busy condition at, the terminating switch. 
     2. Ring-No-Answer—a ring-no-answer condition is defined as a condition where the call is completed to the terminating station, but the call is not answered within a predetermined time period. To determine a ring-no-answer condition, the originating switch begins an overflow timer upon receipt from the terminating switch of a signaling message indicating that the call is ringing. Upon expiration of the timer, overflow action is invoked for the call. Should the terminating switch return an Answer Supervision response to the originating switch prior to the timer expiration, the overflow timer will be canceled. 
     3. ISDN Cause Values—are indicators of the reason a local exchange network (LEN) or a customer premise equipment (CPE), such as a private branch exchange (PBX), cannot complete a call. These indicators are generated by the LEN or CPE and are returned to the originating switch via a signaling message. 
     4. Other—other conditions include network problems that prevent the call from reaching its intended termination, such as, for example, network congestion, a cut cable or blockage of the call by the local exchange network (LEN). Additional information which could be used to indicate conditions include, for example, original access information, such as caller identification, originating switch identification and originating trunk group identification. For another example, attempted termination data could be used, such as terminating switch identification, terminating trunk group type identification, outpulsed address digits and previous database system action codes. 
     The user can specify which condition or combination of conditions is to be acted upon by including those specific conditions in the sequence of overflow statements for the intended termination. It is also possible for the user to specify all conditions in a single statement, rather than specifying each condition separately. 
     If a condition specified in an overflow statement is satisfied, the action indicated in that statement is performed. There are two possible actions: overflow and treatment. 
     1. Overflow—allows users to redirect calls from an intended termination location to a secondary location. 
     2. Treatment—rather than redirecting the call to a secondary termination, the user may prefer to provide a treatment such as, for example, a busy signal, a network announcement or a customized announcement. 
     If an overflow condition which is not included in any specified overflow statements is encountered, overflow processing will not be invoked and the call will receive normal call treatment. 
     The object of overflow statement is typically the service location to which a call will be sent if an overflow action is specified and the overflow condition at the intended service location is met. An object may be any of the termination types allowed for intended terminations. 
     If the action specified is treatment rather than overflow, the object specified may not be a service location. Instead, a treatment type is specified as the object, such as, for example, a busy signal or a network message. 
     Overflow statements may be combined or strung together to form overflow branches. Overflow branches represent a sequential series of overflow instructions to be attempted if a call cannot be completed to the intended termination. FIG. 4 b  is an example of two statements,  410   b  and  420   b , combined to form a short branch statement  400   b . The object, O 1    416   b , of the first statement  410   b  has automatically become the intended service location  422   b  of the second statement. Statement  400   b  specifies: 
     Statement  410   b : if, at intended service location I 1    412   b , condition C 1    414   b  is encountered, overflow the call to object O 1    416   b , which is also intended service location I 2    422   b  for the second overflow statement  420   b.    
     Statement  420   b : if, at intended service location I 2    422   b , condition C 2    424   b  is encountered, overflow the call to object O 2    426   b.    
     Statements may only be combined if the object of the first statement is a service location. Several overflow statements may be combined together in a single branch, one statement for each overflow attempt up to the maximum allowed number of overflow attempts. If a treatment is specified as the object of an overflow statement, the branch is ended and no other statements may be appended. 
     FIG. 4 c  is an example of an overflow sequence  400   c , which loops back upon itself. Statement  400   c  also exemplifies a multiple condition specification. Statement  400   c  specifies: 
     Statement  410   c : if, at intended service location I 1    412   c , at least one of condition C 1 , C 2 , or C n    414   c  is encountered, overflow the call to object O 1    416   c , which is also intended service location I 2    422   c  for the second overflow statement  420   c.    
     Statement  420   c : if, at intended service location I 2    422   c , condition C 2    424   c  is encountered, overflow the call to object O 2    426   c , which is also intended service location I 1    412   c.    
     In the event a non-specified condition occurs, the call will received normal call treatment. The predetermined maximum number of attempts prevents looping indefinitely. 
     At the originally intended termination, it is possible to act on individual conditions uniquely. This allows the user to form “trees” of overflow sequences. In one embodiment, each tree for a given service location may branch only once, on the initial attempt to deliver the call to the originally intended service location. This simplifies the logic for the order entry process. In another embodiment, additional branching is allowed. This increases the flexibility of the overflow process, at the expense of added complexity in the order entry process. 
     FIG. 4 d  is an example of a multiple branch overflow tree. Statement  400   d  has multiple overflow branches  410   d ,  420   d  and  430   d . If the call encounters condition C 1 , which represents a set of one or more conditions, at I 1 , the call will overflow to I 2  and continue down branch one  410   d  until the call is completed., the maximum number of overflow attempts have occurred, or the end of the branch is reached. If the call encounters condition C 2 , which represents a set of one or more conditions, at I 1 , the call will overflow to I 3  and continue down branch  420   d . If the call encounters condition C 3 , which represents a set of one or more conditions, at I 1 , the call will overflow to I 4  and continue down branch  430   d . Once the overflow tree has branched at the original intended service location, it cannot branch again. Only a sequential series of statements may be linked. 
     It is possible to go from tree to tree by linking multiple trees together. Trees may be liked by flagging the last object of a branch to “GOTO” that object&#39;s tree if overflow service has been subscribed and an overflow tree defined for that object. FIG. 4 e  is an example of one overflow tree linked to a second overflow tree. When the call reaches the end of branch  420   e , I 5 , the overflow tree for I 5 , not I 1 , will be used for subsequent overflow attempts. Even though the call has overflowed to a second overflow tree, the original overflow attempt counter is still in effect and the call cannot be overflowed more than the specified maximum number of times. 
     Overflow trees are arranged in a set hierarchy which provides a priority of execution. The highest available level of hierarchy will be executed. As shown in FIG. 4 f , there are three levels in the hierarchy: Default  470 , Outpulse Exception  480  and Dialed Number Exception  490 . The Dialed Number is the pre-translated number; it is the number as dialed by the caller. The Outpulse number is the translated number sent to the terminating service location. Regardless of the level at which a tree is defined, the structure and components of the branches and overflow statements remain the same as described above. 
     The default overflow tree acts as a catch-all for incoming calls to the intended service location. The Outpulse and Dialed Number exception overflow trees provide added layers of granularity for handling overflow traffic for a given service location. 
     When an incoming call cannot be completed and overflow has been subscribed, the network database will search for a match using first the Dialed Number Exception tree, then the Outpulse Exception tree and finally the Default tree. An incoming call may only be matched to one level of overflow tree. This is done at the time the initial overflow condition occurs. 
     There may be multiple overflow trees defined for each level of hierarchy. Each overflow tree may be set to active or inactive. Only trees that are active are screened against incoming calls. For both the Dialed Number and Outpulse levels, multiple overflow trees may be active simultaneously. For the Default level, only one overflow tree can be active at a time. All other trees at the Default level must be set to inactive. The user may change the status—active or inactive—of each overflow sequence as needed. 
     FIG. 5 a  is a flow diagram of process  500 , implemented in network  200  of FIG. 2 a . The process begins with step  502 , in which the caller places a call. In step  504 , the originating switch receives the call. In step  506 , the originating switch sends an initial routing request to the network database. The initial routing request is a request for routing from the originating switch to the desired terminating switch. In step  508 , the network database sends the initial routing to the originating switch. The initial routing is a routing from the originating switch to the desired terminating switch. In step  510 , the originating switch routes the call to the desired terminating switch, based on the initial routing supplied by the network database. 
     In step  512 , the originating switch detects whether the call has been completed. There are two ways in which the originating switch may detect completion failure. First, when the originating switch receives a signaling message that the call has been completed as far as the terminating switch, the originating switch starts a timer. If the timer reaches a predetermined value before the originating switch receives a signaling message indicating that the call has been answered by the termination, the originating switch detects a completion failure. In this way, the originating switch detects a ring-no-answer situation. If the originating switch receives a signaling message indicating that the call has been answered by the termination before the timer has reached a predetermined value, the originating switch detects a call completion. Second, if the originating switch receives a signaling message indicating that the termination is busy, that network congestion or failure prevents completion or that the termination telephone system did not complete the call for some reason, the originating switch detects a completion failure. In the case of the termination telephone system not completing the call, if the termination telephone system is ISDN capable, an ISDN cause value indicating the reason the call was not completed is also received by the originating switch. If the originating switch detects a call completion, the process ends. 
     If the originating switch detects a completion failure, the process goes to step  514 , in which the originating switch releases the call to the terminating switch. In step  516 , the originating switch sends a request for overflow routing to the network database. This request includes the number of the termination to which the call failed to complete and the condition encountered. In step  518 , the network database increments its overflow counter associated with the particular call being handled. In step  520 , the network database determines whether the predetermined maximum overflow count has been exceeded. If so, the process goes to step  528 , in which the network database sends a message indicating that the call should be blocked. In step  530 , the originating switch applies a treatment, such as, for example, playing a busy signal or an audio message to the caller. 
     If the maximum overflow count has not been exceeded, the process goes to step  522 , in which the network database generates and sends an overflow routing to the originating switch. The overflow routing is determined by the network database using one or more overflow statements which specify actions, the conditions under which the actions are to be performed and the objects upon which the actions are to be performed. The relevant information includes, for example, the completion failure condition which was detected and the number of routing attempts which have occurred, as is explained in detail below. In step  524 , the originating switch routes the call to the indicated overflow terminating switch, based on the overflow routing supplied by the network database. 
     In step  526 , the originating switch detects whether the call has been completed, as was done in step  512  above. If the call has been completed, the process ends. If the completion failed, the process loops to step  514 . 
     FIG. 5 b  is a flow diagram of the subprocess of step  522  of FIG. 5 a . Subprocess  522  begins with step  522 - 1 , in which the network database selects the appropriate overflow tree from amongst those stored in memory. The overflow tree set is selected based on the called number included in the overflow routing request message sent by the originating switch. As described above, the network database searches the hierarchy to find active overflow statements. Once the appropriate overflow tree is selected, the appropriate branch is located and the appropriate segment is determined based on the intended termination of the call. In step  522 - 2 , the network database compares the condition or conditions specified in the selected overflow tree segments with the encountered condition as specified in the message from the originating switch. In step  522 - 3 , the network database selects the actions and objects specified in segments having conditions which match the encountered condition. If an overflow condition which is not included in any specified overflow statements is encountered, overflow processing will not be invoked and the call will receive normal call treatment. In step  522 - 4 , the network database sends a message containing an indicator of the selected actions and objects to the originating switch. 
     FIG. 6 is a chart of typical ISDN cause values which may be used as conditions encountered to control overflow processing. Indications of these values are sent from the originating switch to the network database in step  516  of process  500 . The values shown are examples only. The present invention is capable of handling any currently defined values, or any values which may be defined in the future. 
     Although specific embodiments of the present invention have been disclosed, it will be seen by one of skill in the art that other embodiments which are equivalent are possible.