HK1058732A - Method and system for dynamic gateway selection in an ip telephony network - Google Patents

Description

Method and system for dynamic gateway selection in an internet protocol telephony network

Background

Technical Field

The present invention relates generally to the field of Internet Protocol (IP) telephony, and more particularly to a method and system for selecting a gateway for routing a call through a packet-based telecommunications network interconnected with a public telecommunications network. Acronyms

This written description uses many acronyms that refer to various services, messages, and system components. Although well known, the use of several of these acronyms is not strictly standardized in the art. For purposes of the discussion herein, several acronyms are defined as follows:

dynamic Gateway Selection (DGS) -the process employed by network servers and Redirect Servers (RSs) to enable call selection routes to egress gateways.

Egress (destination) and ingress (origin) gateways-gateways that connect internet protocol networks to PSTN, PBX, or other networks.

Network Management System (NMS) -performs various functions including receiving and storing status changes of destination or egress gateways.

Description of the Prior Art

Internet telephony provides real-time transport of voice and other multimedia data between two or more parties over a network employing the Internet Protocol (IP). Internet telephony is session based and not connection based. That is, internet telephony uses a virtual connection or circuit to transfer data between two nodes. These connections between nodes are referred to as "virtual circuits" in order to distinguish them from the dedicated circuits of conventional networks.

IP telephony offers benefits to both users and carriers in terms of cost and diversity of media carried. There are a significant number of conventional telephones served by the Public Switched Telephone Network (PSTN). The PSTN provides a dedicated end-to-end circuit connection for the user for the duration of each call. And reserving a circuit between the transmitting end switch and the receiving end switch according to the called party number.

However, due to the popularity of the internet, many public telecommunications networks now carry IP data traffic in excess of voice data traffic. Public telecommunication networks optimized for voice traffic are not suitable for handling the increasing amount of data traffic. Due to the growth of IP data traffic and the customer demand for low cost integrated voice and data traffic, IP is used as a preferred protocol for carrying voice and data traffic between an originating switch and a terminating switch of a public telecommunications network.

Therefore, in order for IP-based telephony services to be widely accepted by users of traditional telephones, it is necessary to interface the IP telephony network with the existing PSTN and with the private PBX telephone network. To achieve this, a packet-based network, such as the internet, must be directly connected to a public telephone network and act as a bridge between the originating and terminating switches of such a network.

A media stream originating from a public network must be able to be transported over a packet-based IP network and terminated in the same or a different public network. This type of interface is implemented by a gateway that connects signaling and bearer paths between two networks. Thus, an internet gateway performs code and protocol conversions between two incompatible networks to provide the links required to transmit packets between the two different networks, thereby enabling network-to-network connectivity. In order to ensure the reliability of the overall system it is crucial that the gateways are reliable and that their availability, in particular the destination or egress gateway, is monitored in order to quickly and efficiently select an available gateway.

Summary of The Invention

In accordance with the principles of the present invention, a method and system are provided for dynamically selecting an egress (i.e., destination) gateway for establishing a communication session over a path supported at least in part by an IP telephone network and a PSTN, PBX or other network. A Redirect Server (RS) in cooperation with a Network Management System (NMS) employs a gateway selection method that includes recording an egress gateway that is unavailable for a variety of reasons, such as having timed out or failed (i.e., a failure state).

In one embodiment of the present invention, a method is provided for dynamically selecting an egress gateway to enable a call to be completed in a communication session over a path supported at least in part by an IP telephony network and a PSTN, PBX or other network. The IP telephony network comprises a plurality of ingress and egress gateways, at least one Session Initiation Protocol (SIP) proxy server (SPS) and at least one Redirect Server (RS). The Dynamic Gateway Selection (DGS) feature is always active, and is typically invoked whenever the Source User Agent (SUA) initiates a call attempt by sending a session participation request to the SPS.

The best method generally comprises the following steps: a call setup request is received at the SPS from the SUA. The SPS forwards the request to the RS to obtain information for the destination gateway. The RS responds to the SIP session participation request with either a redirect response or a request failure response. The RS redirect response includes a routing list. The routing list is a list of egress (i.e., destination) gateways that are confirmed to be in use. Upon receiving the redirect response from the RS, the SPS acts as a proxy to send a session participation request to the first destination gateway in the routing list. Otherwise, the RS returns a failure response sent to the SUA. Failure response indicates: no destination gateway is in use.

When the SPS sends a request to the destination gateway as a proxy, the SPS waits for a final response from the selected destination gateway. The SPS will receive a final response or timeout information. When the SPS receives the final response from the destination gateway, the SPS sends the final response to the SUA as a proxy, waits for an acknowledgement, and then sends the acknowledgement information as a proxy. Conversely, if the SPS waits for the final response from the destination gateway to time out, the SPS will again send the request a predetermined number of times. If the SPS still times out the last time, the SPS sends a session participation request to the next destination gateway in the routing list provided by the RS.

The process of sending the request is repeated a predetermined number of times for the next destination gateway in the routing list until one of the following occurs: (1) returning a success response; (2) the SPS waits for a final response timeout as described for the first destination gateway in the routing list; (3) the SPS receives an unsuccessful final no server failure response from the currently selected destination gateway; or (4) the destination gateway returns a server failure response, in which case the SPS informs the RS that the destination gateway is failed.

In the second to fourth cases, the SPS sends session participation requests to other destination gateways in the routing list provided by the RS. For each destination gateway that returns a gateway failure response to the SPS, the destination gateway is recorded in the RS as an unusable destination gateway and dynamically deleted from the routing list. Thus, subsequent requests are not sent to the destination gateway of the destination gateway that is recorded as unusable in the RS until after a predetermined amount of time. After a predetermined amount of time has elapsed, the RS automatically restores the failed or unavailable path and sends a report to the Network Management System (NMS) instructing the destination gateway to return to service. The table structure stored in the RS is updated on a real-time basis when a gateway is determined to be unavailable or back in use. When the session participation request has been sent to all destination gateways and no successful response has been received, the SPS returns a final response to the originating medium or calling party to indicate that the call cannot be made.

In another approach, the availability of the destination gateway is determined using a forced reply method. In this method, gateway availability is determined by sending at least one packet to each destination gateway to confirm whether the destination gateway is available or in use. If the destination gateway is in use, it sends an acknowledgement message. If the acknowledgement message is not received after a predetermined period of time, it is determined that the Destination Gateway (DGW) is unavailable. The forced reply method preferably queries each destination gateway one by one and updates the gateway information table by recording the status of each destination gateway.

Accordingly, the present invention provides a variety of functions, including: (1) dynamically detecting failed and unavailable gateways; (2) dynamically deleting failed and unavailable gateways from a routing list, gateway information table, etc. after a predetermined period of time; and (3) automatically recovering the failed and unavailable gateways by updating the gateway status table after a predetermined period of time.

Brief description of the drawings

Various preferred embodiments are now described with reference to the drawings, in which:

FIG. 1 is a block diagram of a preferred embodiment of the present invention;

fig. 2 is a flow chart illustrating a signaling and call setup procedure according to the embodiment of fig. 1;

fig. 3 is a call flow diagram illustrating signaling and call setup procedures according to the embodiment of fig. 1;

fig. 4 is a flow chart illustrating another embodiment of the present invention.

Detailed description of the preferred embodiments

Preferred embodiments of the present invention will now be described with reference to the drawings, wherein like reference numerals designate identical or similar elements. It will be apparent to those skilled in the relevant art that the present invention can operate in many different types of networks without departing from the scope of the invention. In the preferred embodiment described herein, the IP telephony network is preferably the internet. Other examples of networks that may be employed include leased lines, frame relay, and Asynchronous Transfer Mode (ATM) networks.

The present invention provides a method and system for selecting an egress or destination gateway to establish a communication session over a path supported at least in part by an IP telephony network, such as a WAN and PSTN, PBX or other network. The method also determines that the status of the destination gateway is in particular in-use or out-of-use, and automatically returns the destination gateway from the out-of-use status back to in-use after a predetermined amount of time.

Referring now to the drawings, and initially to FIG. 1, a system in accordance with a preferred embodiment of the present invention is indicated generally by the reference numeral 10. System 10 is a telephone network system and includes a first Public Switched Telephone Network (PSTN)114a connected to an IP telephone network or internet 112. The internet 112 is also connected to a second PSTN 114 b. The first PSTN 114a includes a Source User Agent (SUA)102, i.e., an originating agent that issues a session participation request. The second PSTN 114b includes the called party destination user agent (DUA 103). The internet 112 includes a Redirect Server (RS)104, a SIP Proxy Server (SPS)106, a Network Management System (NMS)108, and Destination Gateways (DGWs) 110a, 110 b. Although only two DGWs are shown, it will be understood by those skilled in the art that additional DGWs may be provided. RS104 supports gateway management functions that track DGW status. The NMS 108 receives and stores all state changes about the DGWs 110a, 110 b. The status change is reported by the RS104 to the NMS 108 over the SPS 106. The SPS106 acts as both a server and a client for making requests on behalf of other clients. The SPS106 provides proxy server and gateway resource management functions. SPS106 may be a SIP proxy server or an h.323 gatekeeper.

The method of the present invention, Dynamic Gateway Selection (DGS) and deletion, is performed by SPS106 and RS104 in the context of NMS 108 to allow routing of calls to one of DGWs 110a, 110 b. The dynamic gateway selection and deletion function is specifically invoked when RS104 receives a session participation request. The SUA 102 issues a call attempt and sends a session participation request to the SPS 106. Accordingly, an attempt is made to establish a communication session between the SUA 102 located in the first PSTN 114a and the called party destination Device (DUA)103 located in the second PSTN 114 b. PSTN 114a and 114b are bridged by internet 112.

Fig. 2 is a flow chart illustrating call routing logic for establishing a communication session in accordance with the method of the present invention. At step 702, the user initiates a call attempt by sending a session participation request (i.e., an INVITE request) to the SPS 106. When the INVITE request is an initial request, the SPS106 forwards the initial INVITE request to the RS104 to issue a routing instruction at step 704. At step 705, it is determined whether there is at least one DGW that can satisfy the request. If so, at step 706, the RS104 responds to the SPS106 query with a routing list, i.e., a list of candidate DGWs that can handle the call. RS104 provides a routing list according to the gateway information table stored therein.

If the RS104 determines in step 705 that there is no DGW that can satisfy the INVITE request, a request failure response is returned to the SUA 102 in step 707. Upon receiving the routing list, the SPS106 sends an INVITE request as a proxy to one of the DGWs 110a, 110 b. At step 708, the SPS106 selects the first DGW 110a in the routing list to determine its serviceability and/or availability status. Steps 710 and 712 determine whether the DGW 110a currently selected from the routing list is in a failed state or has timed out. Specifically, at step 710 a determination is made as to whether DGW 110a returned a failure response (i.e., a response could not be used), and if there was a failure response at step 710, SPS106 reports the gateway failure to RS104 at step 714. At step 716, RS104 marks the selected DGW 110a as an unusable destination gateway in a gateway information table stored in RS 104.

In addition, the SPS106 sends a message [ i.e., a Simple Network Management Protocol (SNMP) trap ] to the NMS 108 indicating that the destination gateway has failed. The SPS106 then selects the next DGW 110b in the routing list at step 718. Control returns to step 710 to determine the availability of the next selected DGW 110 b; i.e., whether the next selected gateway 110b is in a failed state or has timed out. If the next selected DGW 110b returns an invalidation response at step 710 or times out at step 712, steps 714 and 718 are repeated. Briefly, the process of selecting a gateway from the routing list and determining whether it is in a failed state or has timed out is repeated until a DGW is found from the routing list to successfully accept the call in step 720. Upon receiving a successful response, the SPS106 forwards the response to the calling user SUA 102 at step 722. The media stream for the call is then established at step 724, thereby establishing a communication link between SUA 102 and DUA 103.

Fig. 3 is a call routing flow diagram illustrating in more detail the call routing logic procedure described above with reference to fig. 2. Table 1 below lists the parameter fields necessary for the INVITE in the preferred embodiment when the SUA 102 initiates a call attempt by sending a session participation request (i.e., INVITE request) to the SPS106 (see item 1 of fig. 1 and step "a" of fig. 3).

TABLE 1

Parameter(s)	Use of
		Request-Line	Including method (i.e., INVITE), Request uniform resource identifier (i.e., Request-URI) and protocol version of SPS
To	Containing the address of the receiver of the request
		From	Containing the address of the initiator of the request
Call-ID	Uniquely identifying the request
		Cseq	Containing the request method and decimal serial number selected by the requesting client, unique within a single value of the Call-ID
Via	Indicating the path taken by the request so far

At SPS106, SIP INVITE is sent to called party DUA 103 at the proxy address. SIP INVITE specifies the real IP address of DUA 103. Upon receipt SIP INVITE, SPS106 sends 100 an attempt message to ingress or originating gateway 105 (fig. 3, step "b"). Table 2 lists the mandatory fields associated with the 100 trying response message in the preferred embodiment.

TABLE 2

Parameter(s)	Use of
		Status-Line	The status code is 100. Reason phrase and protocol version
To	Content copied from original request message
		From	Content copied from original request message
Call-ID	Content copied from original request message
		Cseq	Content copied from original request message
Via	Indicating the path taken by the request so far. If the previous address in the via header field is incorrect, a receive tag parameter is added

SPS106 counts the number of INVITE requests received. If the received request message does not contain a routing header field, it is determined that it is an initial INVITE request message. In this case, the SPS106 performs the following steps: (1) if the "topmost Via header" (TVH) source address is incorrect, adding a "Received" parameter (or replacing the existing one if one already exists) with the source packet into the Via header field inserted by the previous hop; (2) generating an internal Call-ID; or (3) forward the requested message to the RS104 (see item 2 of fig. 1 and step "c" of fig. 3). Table 3 lists the required fields in the RS INVITE request message.

TABLE 3

Parameter(s)	Use of
		Status-Line	Content copied from original request message
To	Content copied from original request message
		From	Content copied from original request message
Call-ID	Internally generated Call-I
		Cseq	Content copied from original request message
Via	Adding a receipt tag

In response to receiving the RS INVITE request from the SPS106, the RS104 performs the following: (1) counting the number of received INVITE messages; and (2) determining that the user portion of the Request uniform resource identifier (i.e., Request-URI) is less than or equal to 15 digits and does not contain a leading 0 or 1. The gateway information table stored in RS104 is used to create an updated routing list.

For example, when a gateway address is marked as unusable in the gateway information table stored in the RS104 and its associated time value is zero, the gateway address is not added to the routing list. When the gateway address is marked as unusable in the gateway information table and its associated time value is greater than the current absolute RS time, then the gateway address is not added to the routing list. When the gateway address is marked as out-of-service in the gateway information table and its associated time value is less than or equal to the current absolute RS time, the gateway address is added to the routing list and marked as in-service in the gateway information table. RS104 also sends a message, i.e., a "simple network management protocol" (SNMP) trap, to NMS 108 indicating that the DGW is in use. If there is only one gateway in the routing list, RS104 sends 302 a response message back to SPS106 (see fig. 1, item 3, and fig. 5, step "d"). RS104 increments a counter that counts the number of 3xx messages sent. Table 4 lists the required fields in one example of a 3xx (302 in this example) response message and a list of contact addresses.

TABLE 4

Parameter(s)	Use of
		Status-Line	The status code is 302. Reason phrase and protocol version
To	Content copied from original INVITE request
		From	Content copied from original INVITE request
Call-ID	Content copied from original INVITE request
		Cseq	Content copied from original INVITE request
Via	Content copied from original INVITE request
		Contact	Multiple gateway addresses

Table 5 lists the required fields in the SNMP trap message sent to the NMS.

TABLE 5

Parameter(s)	Use of
		Protocol Data Unit (PDU) type	Indicates that this is a trap PD
Enterprise (organization)	The network management subsystem that generated the trap is identified. Its value is taken from sysObjectID in the sys group
		Agent-addr	Generating the IP address of the object of the trap
Generic-trap	6 ═ enterprisetspecificic (tissue specific). This value indicates that the sending protocol entity knows that some organization specific event has occurred. The specific-trap field indicates the type of trap
		Specific-trap	Code more specifically specifying trap attributes
Time-stamp	Time between last initialization (re-initialization) of the network entity issuing the trap and trap generation
		Variable bindings	Return 5xx responses and status (atIn use) of the gateway

In the case where there is more than one gateway in the routing list, the RS104 sends a 300 response message back to the SPS106 instead of a 302 response message for a single gateway. RS104 also counts the number of 3xx responses sent for the 300 response. Table 6 lists 300 the required fields in the example of the response message and the contact address list.

TABLE 6

Parameter(s)	Use of
		Status-Line	The status code is 300. Reason phrase and protocol version
To	Same as the original INVITE
		From	Content copied from original INVITE request
Call-ID	Content copied from original INVITE request
		Cseq	Content copied from original INVITE request
Via	Content copied from original INVITE request

Contact

Multiple reachable addresses

The SPS106 counts the number of routing responses received from the RS 104. The SPS106 sends an INVITE to the first DGW 110a and inserts a "user _ phone" header into each contact list address (see figure 1, item 4 and figure 3 step "e"). Table 7 lists the required fields for the INVITE request sent from SPS106 to DGW 110 a.

TABLE 7

Parameter(s)	Use of
		Request-Line	Including method (e.g., INVITE), using Request-URI and protocol version from gateway at top of unused contact list
To	Content copied from original request message
		From	Content copied from original request message
Call-ID	Content copied from original request message
		Cseq	Content copied from original request message
Via	Add NS URL to Top
		Record Route	Request-URI of NS

SPS106 may receive a 100 trying response (see fig. 3 step "f") or a 180 ringing response (see fig. 3 step "g") from DGW 110 a. Table 8 lists the required fields for the 180 ringing response.

TABLE 8

Parameter(s)	Use of
		Status-Line	The status code is 180. Reason phrase and protocol version
To	Same as the original INVITE request plus tag
		From	Same INVITE request sent to egress gateway
Call-ID	Same INVITE request sent to egress gateway
		Cseq	Same INVITE request sent to egress gateway
Via	And send to outINVITE request identity for gateway

After receiving the 180 ringing response from DGW 110a, SPS106 deletes itself from the top of the Via domain, restarts the inviting User Agent (UA) timer (if it exists), and forwards the 180 ringing response to the ingress gateway (see fig. 3, step "g"). The response message is sent to the address indicated in the Via header field. Table 9 lists the necessary message elements.

TABLE 9

Parameter(s)	Use of
		Status Line	Content replicated from 180 responses received by the gateway
To	Content replicated from 180 responses received by the gateway
		From	Content replicated from 180 responses received by the gateway
Call-ID	Content replicated from 180 responses received by the gateway
		Cseq	Content replicated from 180 responses received by the gateway
Via	Content copied from received NS URL deleted 180 response

The SPS receives the INVITE response (i.e., 200 OK response) from DGW 110a (see step "h 1" of fig. 3). Table 10 lists the required fields in the INVITE message.

Watch 10

Parameter(s)	Use of
		Status Line	The status code is 200. Reason phrase and protocol version
To	Same as the original INVITE request plus tag
		From	Same INVITE request sent to egress gateway
Call-ID	Same INVITE request sent to egress gateway
		Cseq	Same INVITE request sent to egress gateway
Record Route	Request-URI of NS
		Contact	Reachable address of egress gateway

After receiving the 200 OK response from the DGW 110a, the SPS106 performs the following steps: (1) cancel the invite UA timer (if present); (2) deleting the SPS URL from the "top-level Via header" (TMVH) field; (3) adding the Request-URI of the next hop to the top of the record-route header field when any of the following conditions is met: a) no contact header field in the 200 OK response, or b) the SPS URL is in the top entry of the record-route header field; (4) count the number of 200 INVITE responses sent by SPS 106; and (5) the SPS106 starts an ACK (acknowledgement) timer. The SPS106 forwards the INVITE response (i.e., 200 OK response) to the ingress gateway (see step "h 1" in fig. 3). Table 11 lists the required fields in the INVITE response.

TABLE 11

Parameter(s)	Use of
		Status-Line	The status code is 200. Reason phrase and protocol version
To	Same as the original INVITE request plus tag
		From	Same INVITE request sent to egress gateway
Call-ID	Same INVITE request sent to egress gateway
		Cseq	Same INVITE request sent to egress gateway
Via	Content from INVITE request sent to egress gateway
		Record Route	Request-URI of NS
Contact	Reachable address of egress gateway

The SPS106 receives the acknowledgement response from the ingress gateway and stops the acknowledgement timer. SPS106 counts the number of acknowledgement response messages received by SPS 106. Table 12 lists the necessary headers for the acknowledgement response (see step "k" of fig. 3).

TABLE 12

Parameter(s)	Use of
		Request-Line	Including method (e.g., ACK), Request-URI for NS, and protocol version
To	Same as the original INVITE plus tag

From	Same as the original INVITE
		Call-ID	Same as the original INVITE
Cseq	Same sequence number as original INVITE
		Via	Originating UA

The received acknowledgement response may contain a routing header field. The SPS106 either proxies the acknowledgement response with the address in the routing header or uses the address in the "To" header To determine whether To proxy or consume the acknowledgement response. When the "To" header address is equal To the SPS address and there is no routing header in the acknowledgement response, the acknowledgement response will be consumed. When SPS106 determines that the proxy acknowledges the response, SPS106 performs the following operations: (1) the SPS106 adds the confirmed address to the top of the Via domain; (2) the SPS106 deletes the top address from the routing header field; (3) the Request-URI is set at an address at the top of the routing header field; and (4) forward the acknowledgement message to DGW 110a based on the top address in the routing header field (if any) or based on DGW information for the call context (context) (see step "1" in figure 3). Thus, DGW 110a is selected as the available gateway to complete the call. If it is determined that DGW 110a is not available, then the same method as described above is used to determine whether DGW 110b is available. If neither DGW is available, a message is sent to the SUA 102 informing that the call cannot be completed. Table 13 lists the parameters of the acknowledgement request message sent to DGW 110 a.

Watch 13

Parameter(s)	Use of
		Request-Line	Containing methods (e.g. ACK), Request-URI copied from the top list of the "route" header field, and protocol version
To	Content replicated from acknowledgements received at an ingress gateway
		From	Content replicated from acknowledgements received at an ingress gateway
Call-ID	Content replicated from acknowledgements received at an ingress gateway
		Cseq	Content replicated from acknowledgements received at an ingress gateway
Via	UA added to the top of Via Domain and starting with NS URL

In another preferred approach, a forced response approach is used to select the DGW. In this embodiment, gateway availability is determined by sending at least one packet to each destination gateway to confirm whether the destination gateway is available or in use. Thus, if the destination gateway is in use, it will send an acknowledgement message. If the acknowledgement message is not received after a predetermined period of time, the DGW is determined to be unavailable. The forced reply method preferably queries each destination gateway one by one and updates the gateway information table by recording the status of each gateway. For example, if an acknowledgement message is received, the DGW is then checked to determine if it is available, and if so, its address is stored in the gateway information table, and the process is repeated for the next DGW.

Fig. 4 is a flowchart illustrating a method, i.e., a forced response method, according to another embodiment of the present invention. A counter is started at step 800 to indicate the destination gateway currently selected from the routing list (i.e., i-1 indicates the number of the gateway in the routing list). At step 802, a message is sent from a server (e.g., proxy server, redirect server) to the ith destination gateway to obtain a response. At step 804, the server waits for a response from the ith destination gateway. Step 806 is a decision step that determines whether a response has been received from the ith destination gateway. If no response is received within the predetermined time, the process continues to step 807 where the ith gateway is marked as unusable or unavailable. At step 808, a determination is made as to whether there are other destination gateways in the routing list to check. If not, processing terminates at step 810. Otherwise, at step 812, the counter is incremented to select a subsequent destination gateway from the routing list.

Step 802 and 806 are then repeated to check the response and/or availability of subsequent (i.e., i +1 th) destination gateways in the routing list. If at step 806 it is determined that the response was received within the predetermined time, processing continues to step 814 where it is further determined whether a response destination gateway is available. If the destination gateway is not available, processing returns to step 807 where the destination gateway is marked as unavailable or unavailable. At step 808, it is then determined whether there are other destination gateways in the routing list to check. If so, step 802 and 806 are repeated for subsequent destination gateways. Otherwise, if it is determined at step 814 that the destination gateway is available in response, processing continues to step 816 where the destination gateway is marked as available in the gateway status table. The process returns to step 808 to determine if there are other destination gateways in the routing list to check.

The description herein is merely illustrative of the application of the principles of the invention. For example, the above-described functions for performing the present invention are merely for illustration. Other devices and methods may be implemented by those skilled in the art without departing from the scope and spirit of the present invention.

Claims (22)

1. A method for routing a call to a destination gateway to establish a communication session call in a telecommunications network over a path supported at least in part by the telephone network and an IP network, the IP network including a plurality of ingress and destination gateways, at least one proxy server, and at least one Redirect Server (RS), the method comprising the steps of:

a) receiving a call setup request from a source user agent at the at least one proxy server;

b) forwarding the received call setup request to the redirect server to obtain routing information;

c) responding to the forwarded call setup request received at the redirect server by returning the routing information or a request failure response;

d) upon receiving the routing information from the redirect server, sending, by the at least one proxy server as a proxy, the call setup request to a destination gateway selected from the routing information;

e) waiting in the at least one proxy server for a response from the selected destination gateway when the call setup request is proxied to the selected destination gateway by the at least one proxy server;

f) establishing a communication session with the selected destination gateway when the at least one proxy server receives the response from the selected destination gateway within a predetermined time; and

g) if the response is not received within a predetermined time, the call setup request is sent to a subsequent destination gateway selected from the routing information.

2. The method of claim 1, further comprising repeating steps (d) through (g) until one destination gateway is determined to be available for establishing the communication session or until all destination gateways in the routing information have been determined to be unavailable.

3. The method of claim 1, further comprising the steps of:

recording a status of a destination gateway as unavailable if a response from the destination gateway is not received within a predetermined time;

recording a status of the destination gateway as unavailable if the response from the selected destination indicates that the destination gateway is unavailable.

4. The method of claim 3, wherein the recording step records the status of the destination gateway as unusable in a gateway information table stored in the RS.

5. The method of claim 1, wherein said step of receiving a call setup request at said at least one proxy server from a source user agent comprises the step of sending said call setup request to a proxy address of said at least one proxy server.

6. The method of claim 1, wherein said step of receiving at said at least one proxy server a call setup request from a source user agent comprises counting at said at least one proxy server a number of requests received after said call setup request.

7. The method of claim 1, wherein the at least one proxy server comprises a Session Initiation Protocol (SIP) proxy server.

8. The method of claim 1, wherein the at least one proxy server comprises an h.323 gatekeeper.

9. The method of claim 1, wherein the step of responding to call setup requests received at the RS forwarded from the at least one proxy server comprises determining a status of a set of destination gateways.

10. The method of claim 9, wherein the status of each destination gateway in the set of destination gateways is one of "in use" and "out of use".

11. The method of claim 10, wherein the gateway address is not added to the routing list of the routing information if the status of the destination gateway is recorded as unavailable in the gateway information table and its associated time value is greater than the current absolute RS time.

12. The method of claim 10, wherein if the status of a destination gateway is recorded as out-of-service in a gateway information table and its associated time value is less than or equal to the current absolute RS time, the gateway address is added to a routing list of the routing information and recorded as in-service.

13. The method of claim 10, further comprising the step of sending a message from the RS to the network manager to record the status of the destination gateway.

14. The method of claim 1, further comprising the steps of: upon receiving the request failure response from the at least one proxy server, forwarding the request failure response to the source user intermediary and terminating the communication session.

15. The method of claim 1, further comprising the steps of: the call setup request is resent to the selected destination gateway a predetermined number of times when no response is received within a predetermined time.

16. A system for enabling a call to be completed in a communication session between a calling party and a called party, comprising:

a first telephony system including at least one Service User Agent (SUA);

a second telephone system including at least one Destination User Agent (DUA);

an IP network connected between said first and second telephone systems;

a plurality of ingress gateways for connecting the IP network with the first telephony system;

a plurality of egress gateways for connecting the IP network with the second telephony system;

an IP telephony proxy server for selecting one of the plurality of egress gateways to complete the call;

an IP redirect server for providing routing information to the IP telephony proxy server; and

a network management system for receiving and storing a change in status of a destination gateway, the network management system in communication with the IP redirect server.

17. The system of claim 16, wherein the IP telephony proxy server is a "session initiation protocol" (SIP) proxy server.

18. The system of claim 16, wherein the IP telephony proxy server is an h.323 gatekeeper.

19. A method for detecting an available destination gateway from a plurality of destination gateways in an IP network for completing a communication session between a calling party and a called party, the method comprising the steps of:

a) sending a message from a server to one of the plurality of destination gateways to confirm an availability status of the one of the plurality of destination gateways;

b) waiting for an acknowledgement response from said one of said plurality of destination gateways for a predetermined period of time;

c) determining whether said one of said plurality of destination gateways is available if said acknowledgement response is received within said predetermined period of time and indicates that said destination gateway is available; and

d) sending the message to a subsequent gateway of the plurality of destination gateways.

20. The method of claim 19, further comprising repeating steps (b) through (d) until an availability status of each of the plurality of destination gateways has been determined.

21. The method of claim 19, wherein the availability status of the destination gateway is deemed unusable if the acknowledgement response is not received within a predetermined period of time.

22. The method of claim 19, wherein the availability status is determined to be in use if the one of the plurality of destination gateways is determined to be available.