CA2391037A1 - Method and system for dynamic gateway selection in an ip telephony network - Google Patents
Method and system for dynamic gateway selection in an ip telephony network Download PDFInfo
- Publication number
- CA2391037A1 CA2391037A1 CA002391037A CA2391037A CA2391037A1 CA 2391037 A1 CA2391037 A1 CA 2391037A1 CA 002391037 A CA002391037 A CA 002391037A CA 2391037 A CA2391037 A CA 2391037A CA 2391037 A1 CA2391037 A1 CA 2391037A1
- Authority
- CA
- Canada
- Prior art keywords
- gateway
- destination
- proxy server
- gateways
- response
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 230000004044 response Effects 0.000 claims description 83
- 238000004891 communication Methods 0.000 claims description 13
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 235000008733 Citrus aurantifolia Nutrition 0.000 claims 1
- 235000011941 Tilia x europaea Nutrition 0.000 claims 1
- 239000004571 lime Substances 0.000 claims 1
- 230000008569 process Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 9
- 239000003795 chemical substances by application Substances 0.000 description 6
- 238000010586 diagram Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 230000027455 binding Effects 0.000 description 1
- 238000009739 binding Methods 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1023—Media gateways
- H04L65/103—Media gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1033—Signalling gateways
- H04L65/104—Signalling gateways in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/102—Gateways
- H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
- H04M7/1285—Details of finding and selecting a gateway for a particular call
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
Abstract
This invention relates to the field of Internet Protocol telephony. More particularly, this invention is a method and system for selecting gateways for routing calls through a packet-based telecommunications network interconnected with a public switched telecommunications network. With reference to Fig. 1, this invention is a method and system for dynamically selecting (1-11) a destination gateway (110a, 110b) to complete a call over a path (12) supported at least in part by an IP telephony network (112) and a public switched telephone network (114a, 114b). The method and system further provide for dynamically detecting available gateways (110a, 110b), dynamically removing failed and/or unavailable gateways (6-8), and automatically recovering failed and/or unavailable gateways after a predetermined period of time (6-8).
Description
METHOD~ND SYSTEM FOR QYNAMI~ GA'rEWAI~ SELECTi'ON
IN AN IP TELEPHONY NETI~(ORK
BA KGROU~ta O>= THE INVENTI~~N
1. Pigid Qf the Inyention The present invention relates generally to the field of IP telephony, and more particularly to a method and system for selecting gateways) for routing calls through a packet-based telecommunications network interconnected with a public telecommunications network.
IN AN IP TELEPHONY NETI~(ORK
BA KGROU~ta O>= THE INVENTI~~N
1. Pigid Qf the Inyention The present invention relates generally to the field of IP telephony, and more particularly to a method and system for selecting gateways) for routing calls through a packet-based telecommunications network interconnected with a public telecommunications network.
2. Acronyms The written description herein uses a number of acronyms to refer to various services, messages and system components. Although generally known, use of several of these acronyms Is not strictly standardized in the art. For purposes of this discussion, several acronyms will b~ defined as follows:
Dynamic Gafeway Se!~cfion (DGS) - a process employed by a network server and a Redirect Server (RS) to allow calls to be routed to an egress gateway.
Egress (Destinafion) and lngness (Origination) Gateways - gateways connecting an IP
network to a PSTN, PBX or other network .
Network Management System (NMS) - performs a variety of functions, including receiving and storing status changes to destination or egress gateways.
Dynamic Gafeway Se!~cfion (DGS) - a process employed by a network server and a Redirect Server (RS) to allow calls to be routed to an egress gateway.
Egress (Destinafion) and lngness (Origination) Gateways - gateways connecting an IP
network to a PSTN, PBX or other network .
Network Management System (NMS) - performs a variety of functions, including receiving and storing status changes to destination or egress gateways.
3.17e rri prl Internet telephony provides real-time delivery of voice, and other multimedia data, between two or more parties across a network employing Internet protocols (1P).
Internet telephony is session-based rather than connection-based. That is, Internet telephony uses virtual connections or circuits to pass data between two nodes.
These connections between the nodes are tem~ed "virtual circuits" to distinguish them from dedicated circuits of conventional networks.
While IP telephony offers benefits to both users and carriers in terms of costs and variety of media types that can be routed threrethrough, there are a substantial amount of traditional telephones being serviced by the Public Switched Telephone Network (PSTN). The PSTN provides users with dedicated, end-to-end circuit connections for the duration of each call. Circuits are reserved between an originating switch and a terminating switch based on a called party number.
However, because of the popularity of the Internet, many public telecommunications networks now carry significantly more IP data traffic than voice data traffic. Public telecommunications networks, optimized for voice traffic, are ill-
Internet telephony is session-based rather than connection-based. That is, Internet telephony uses virtual connections or circuits to pass data between two nodes.
These connections between the nodes are tem~ed "virtual circuits" to distinguish them from dedicated circuits of conventional networks.
While IP telephony offers benefits to both users and carriers in terms of costs and variety of media types that can be routed threrethrough, there are a substantial amount of traditional telephones being serviced by the Public Switched Telephone Network (PSTN). The PSTN provides users with dedicated, end-to-end circuit connections for the duration of each call. Circuits are reserved between an originating switch and a terminating switch based on a called party number.
However, because of the popularity of the Internet, many public telecommunications networks now carry significantly more IP data traffic than voice data traffic. Public telecommunications networks, optimized for voice traffic, are ill-
4 PCT/US00/41994 equipped to handle increasing data traffic volumes. The growth in IP data traffic coupled with customer demands for integrated voice and data services at lower costs has led to the adoption of IP as the preferred protocols for canyinq both voice and data traffic between originating and terminating switches of the public telecommunications network.
Accordingly, in order for IP based telephony services to become broadly accepted by users of traditional telephones, it is necessary to interface the IP telephony network with the existing PSTN and with private PBX phone networks. To permit this mode of operation, a packet-based network, such as the Internet, must intertace directly with public telephone networks and operate as a bridge between originating and destination switches of such networks.
Media streams which originate from a public network must be capable of being transported through the packet-switched IP network and terminate at the same or different public network. This type of interfacing is pertormed by gateways which interface the signaling and bearer paths between the two networks. Therefore, Internet gateways perform code and protocol conversion between two otherwise incompatible networks to provide links necessary to send packets between the two different networks and thus make network-to-network connections possible. To assure overall system reliability it is crucial that the gateways are reliable and their availability, especially destination or egress gateways, be monitored for quickly and efficiently selecting an available gateway.
SUMMARY Of THE INVENTION
In accordance with the principles of the invention, a method and system are provided by which an egress (i.e., destination) gateway is dynamically selected to establish a communication session over a path supported at least in part by an IP
telephony network and 9 PSTN, PBX or other network. A redirect server (RS) in concert with a network management system (NMS) employs a gateway selection methodology which includes recording egress gateways which are not available due to several reasons, such as having timed out, or having a malfunction, i.e..
failure status.
In one embodiment of the present invention, a method is provided for dynamically selecting an egress gateway to allow 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 !P telephony network indudes a plurality of ingress and egress gateways, at least one Session Initiation Protocol (SIP) proxy server (SPS) and at least one redirect server (RS). A dynamic gateway selection (DGS) feature is always active and is typically invoked whenever a source user agent (SUA) initiates a call attempt by sending a session participation request to the SPS.
The preferred method generally includes the steps of: receivinfl a call setup request at the SPS from the SUA. The SpS forwards the request to the RS to obtain information of destination gateways. The RS responds to the SIP session participation request with either a redirection response or a request failure response. The RS
redirection response includes a routing list. The routing list is a list of egress (1e., destination) gateways that are determined to be in-service. Upon receipt of a redirection response from the RS, the SPS proxies the session participation request to a first destination gateway in the routing list. Otherwise, the RS returns a failuro response which is sent to the SUA. The failure response is an indication that there are no destination gateways having an in-service status.
When the SPS proxies the request to a destination gateway, the SPS waits for a final response from the selected destination gateway. The SPS will either receive a final response or time-out. When the SPS receives a final response from the destination gateway, the SPS proxies the final response to tfie SUA, awaits an acknowledgment and proxies the acknowledgment. Otherwise, when thA SPS times-out waiting for a final response from the destination gateway, the SPS re-sends the request a predetermined number of times. If the SPS times-out for a final time, the SPS
sends the session participation request to the next destination gateway in the routing list provided by the RS.
The process of sending a request a predetermined number of times is repeated for the next destination gateway iA the routing list until one of the following occurs: (1 ) a success response is returned; (2) the SPS times-out waiting for a final response, as described above with respect to the first destination gateway in the routing list; (3) the SPS receives an unsuccessful final, non-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 of the destination gateway failure.
In case of the second to fourth situations, the SPS sends the session participation request 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 as an out-of service destination gateway in the RS
and is dynamically removed from the routing list. Therefore, subsequent requests are not sent to destination gateways which are recorded as out-of service destination gateways in the RS until after a predetermined amount of time. After the predetermined amount of time has elapsed, the RS automatically recovers failed or out-of service pathways and issues a report to a network management system (NMS) indicating that the destination gateway is back in service. Table structures, stored within the RS, are updated on a real-time basis when it is determined that a gateway is out-of service or back in-service. When the session participation request has been sent to all destination .gateways and no successful response is received, the SPS returns a final response to the originating agent or calling party indicating that a call cannot be made.
In an alternative method, availability of destination gateways is determined using a ping method. In this method, gateway availability is determined by sending at least one packet to each destination gateway to ascertain whether the destination gateway is available, or in-service. If the destination gateway is in-service, it transmits an ACK
message. If an ACK message is not received after a predetermined period of time, the destination gateway (DGW) is determined to be unavailable. The ping method preferably pueries each destination gateway one-by-on~ and updates gateway information tables by recording the status of each destination gateway.
The present invention thereby provides several functions, including: (i ) dynamic detection of failed and unavailable gateways; (2) dynamic removal of failed and unavailable gateways) from a routing list, gateway information table, etc., after a predetermined period of time; and (3) automatic recovery of failed and unavailable gateways by updating gateway status tables after a predetermined period of time.
Various preferred embodiments are described herein with reference to the accompanying drawings, in which:
FIG. 1 is a block diagram of a preferred embodiment of the present invention;
FIG. 2 is a flowchart illustrating signaling and call setup procedures according to the embodiment of F1C3.1;
FIG. 3 is a call flow diagram illustrating the signaling and call setup procedures according to the embodiment of FIG. 1; and FIG. 4 is a flowchart illustrating an alternate embodiment of the present invention.
DETAILEQ DESCRIPTION OF THE PREFI~I~tRED EMBODIMENTS
Prefer-ed embodiments of the present invention will now be described with reference to the figures where like reference numbers indicate identical or similar elements. It will be apparent to persons skilled in the relevant art that the present invention can operate on many different types of networks without departing from the scope of the present invention. In the preferred embodiments described herein, the 1P
telephony network is preferably the Internet. Other examples of networks which could be used include leased lines, frame delay, 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 a PSTN, PBX or other network. The method further determines the status of a destination gatewgy, particularly, as being either in-service or out-of service, and automatically brings a destination gateway back into service from an out-of service state after a predetermined amount of time.
Referring now to the drawings, and first to FIG.1, a system according to a preferred embodiment of the present invention is designated generally by reference numeral 10. System 10 is a telephony network system and includes a first public switched telephone network (PSTN) 114a which interfaces to an IP telephony network or Internet 112_ The Internet 112 is further interFaced to a second PSTN 114b.
The first PSTN 114a includes a source user agent (SUA) 102, i.e.. originating agent, which originates a session participation request. The second PSTN 114b indudes a called party destination user agent (DUA 103). The Internet 112 indudes a redirect server (RS) 104, an SIP proxy server (SPS) 106, a Network Management System (NMS) 108, and destination gateways (DGWs) 110a, 110b. While only two DGWs are shown, one of ordinary skill in the art will recognize that additional DGWs may be provided. The RS
104 supports a gateway management function which tracks the status of the DGWs.
The NMS 108 receives and stores all status changes regarding DGWs 110a, 110b.
Status changes are reported to the NMS 108 by the RS 104 via the SPS 106. SPS
acts as both a server and client for the purpose of making requests on behalf of other clients. SPS 106 provides proxy server and gateway resource management functions.
SPS 106 may be a SIP proxy server or an H.323 gatekeeper.
The method of the present invention (i.e., dynamic gateway selection (DGS) and removal) is performed by the SPS 106 and RS 104 in context with the NMS 108 in order to allow calls to be routed to one of the DGWs 110a , 110b. The dynamic gateway selection and removal feature is particularly invoked upon receipt by the RS
104 of a session participation request. The SUA 102 initiates a call attempt to transmit the 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
114b. PSTN 114a and 114b are bridged via the Internet 112.
FIG. 2 is a flowchart illustrating the call routing logic for establishing a communication session in accordance with the methodology of the present invention.
At step 702, a user initiates a call attempt by sending a session participation request (1e., an INVITE request) to the SPS 106. When the INVITE request is an initial request, tha SPS 106 forwards the initial INVITE request to the RS 104 for routing instructions at step 704. At step 705, it is determined whether there is et least one DGW that can satisfy the request. If so, at step 706, the RS 104 responds to the SPS
106 query with a routing list, Le., a list of candidate DGWs that can handle the call. The RS 104 supplies the routing list from a gateway information table stored therein.
In the event the RS 104 determines that there are no DGWs that can satisfy the INVITE request, at step 705, a request failure response is returned to the SUA
102, at step 707. Upon receiving the routing list, the SPS 106 proxies the INVITE
request to one of the DGWs 110a, 110b. At Step 708, the SPS 106 selects the first DGW
110a in the routing list to determine Its serviceability and/or availability status.
Steps 710 and 712 determine whether the currently selected DGW 110a from the routing list is in a failure state or has timed out. Specifically, at step 710, a determination is made concerning whether the DGW 110a returns a failure response (i.e., out-of service response). If there is a failure response at step 710, the SPS 106 reports the gateway failure to the RS 104 at step 714. The RS 104 marks the selected~DGW 110a as an out-of-service destination gateway in a gateway information table stored in the RS 104, at step 716.
In addition, the SPS 106 sends a message, (i.e., Simple Network Management Protocol (SNMP) trap), to the NMS 108 indicating a destination gateway failure. The SPS 106 then selects the next DGW 110b in the routing list, at step 718.
Control then returns to step 710 to determine the availability of the next selected DGW
110b; that is, whether the next selected gateway 110b is in a failure state or has timed out.
If the next selected DGW 110b returns either a failure response at step 710, or times-out at step 712, then steps 714-718 are repeated. In short, the process of selecting a gateway from the routing list and determining whether it is in a failure state or has timed out is repeated until a bGW Is found from the routing list which accepts a call with a success response at step 720. When a success response is received, the SPS
10fi forwards the response to the calling user SUA 102 at step 722. The media stream for the call is then set up at step 724 to establish a communication link between the SUA
102 and DUA 103.
FIG. 3 is a call routing flow diagram illustrating in greater detail the call routing logic procedure described above with reference to FIG. 2. Table 1 below lists the INVITE required parameter fields in the preferred embodiment when a SUA 102 Initiates a call attempt by sending a session participation request (i.e., an INVITE
request) to the SPS 10fi (See FlG.I, item 1 and FIG. 3, step "a").
Table 1 Parameter Usage Request-LineContains the method (e.g., INVITE), Request Uniform Resource Ident'rtier (1e., Request-URI) of the SPS and protocol version To Contains the address of the recipient of the request From Contains the address of the initiator of the request Call-ID ~ Uniquely identifies the invitation Cseq Contains the request method and a decimal sequence number chosen by the requesting client, unique within a stn le value of the Call-ID
Via Indicates the path taken by the request so far The SIP INVITE is addressed to the called party DUA 103 at a proxy address at the SPS 106. The SIP INVITE specifies the real IP address of the DUA 103. Upon receipt of the SIP INVITE, the SPS 106 sends a 100 trying message to the ingress or origination gateway (FIG. 3, step "b"). Table 2 lists the mandatory fields associated with the 100 trying response message in the preferred embodiment.
Table 2 Parameter Usage Status-LineStatus Code =100, Reason phrase and protocol VerSiOn To Content copied from the original request message From Content copied from the original request mocs~ge Call-ID Content copies from tho original request message Cseq Content copies from the original request message Via Indicates the path taken by the request so far. Add the received-tag parameter if the previous ho address is ink in the via header field The SPS 106 counts the number of INVITE requests received. When a received request message does not contain a route header field, it is determined to be an initial INVITE request message. In such a case, the SPS 106 performs the following steps:
(1 ) if a Topmost Via Header ('TVH) source address is incorrect, adds a "Received"
parameter (or replaces the existing one if there is one) with the source package to the Via header field inserted by the previous hop; (2) generates an internal Call-ID; or (3) forwards the requested message to the RS 104 (See FIG. 1, item 2 and FIG. 3, step 'c'). Table 3 lists the required fields in the RS INVITE request message.
Table 3 Parameter Usage Status-Llne Content copied from the original request message To Content copied hom the original request message From Content copied from the original request message Call-ID Internally generated Call-I
Cseq Content copied from the original request message Vi8 Add the r~eoe'rved tag In response to receiving the RS INVITE request message from the SPS 106 , the RS 104 performs the following: (1) counts the number of INVITE messages received;
(2) determines that the user portion of 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;
and (3) queries a Network Control SysternlData Access Point (i.e., NCS/DAP) to obtain routing information (FIG. 3, step °d"). Routyng information, including a routing list of prospective DGWs, is then sent from the NCS/DAP to the RS 104 (FIG. 3, step "e").
The routing information is used to update the gateway information table stored in RS
104_ The gateway information table is subsequently used to create an updated routing list.
For example, when a gateway address is marked as out-of service in the gateway information table stored in RS 104 and its associated time value is zero 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 greater than the current absolute RS time, 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 the gateway address is marked as in-service in the gateway information table. The RS 704 also sends a message, i.e., the Simple Network Management Protocol (SNMP) trap, to the NMS 108 indicating that the DGW is in-service. If there is only one gateway in the routing list, the RS 104 will send a 302 response message back to the SPS 106 (See FIG. 1, item 3 and FIG. 3, step "f"). The RS 104 increments a eounterwhich Counts the number of 3~oc messages sent. Table 4 lists the required fields in the 3xx (302 in the present case) response message and an ~exampte of the contact address list.
T2~ble 4 Parameter Usage Status-LineStatus Code = 302, Reason phrase and protocol version To Content copied from the Original INVffE request From Content capIed from the Original INVITE request Call-ID Content copied from the Original INVITE request Cseq Content copied from the Original INVITE request Via Content copied from the Original INVITE requaat Contact Multiple gateway addresses Table 5 Ilsts the required fields in the SNMP trap message to the NMS.
Table 5 Parameter Usage Protocol Indicates that this is a Trap PD
Data Unit (PDU) Type Enterprise Identifies the network-management subsystem that generated the trap, Its value is taken from sysobjectlD In the system Group Agent-addr The IP address of the object generating the tra Generic-trap6 = enterpriseSpecific. This value signifies that the sending protocol entity recognizes that some enterprise-specific event has occurred.
The specifi~trap field indicates the type of trap Specfic-trapA code that indicate more specifically the nature of the trap Time-stamp The time between the last (re)initialization of the network entity that issued the trap and the generation of the trap Variable The address of the gateway that returned the 5xx bindings responss and status (In-service) In the case where there is more than one gateway in the routing list, the RS
sends a 300 response message, instead of a 302 response message for a single gateway, back to the SPS 106. For a 300 response, the RS 104 also counts the number of 3~ot responses sent. Table 6 lists the required fields in the 300 response message and an example of the contact address list.
Tablo 6 Parameter Usage Status-LineStatus Code = 300, Reason phrase and protocol version To Same as the original INVITE
From Content copied from the Original INVITE request Cat!-ID Content copied from the Original INVITE request Cseq Content copied from the Original INVITE request Via Content copied fr~nm the Original INVITE request Contact Multiple reachable addresses The SPS 106 counts the number of routing responses received from tho RS 104.
The SPS 106 sends an INVITE to the first DGW 110x, and inserts the °user-phone°
header in each contact list address (See FIG. 1, item 4 and FIG. 3, step ~g").
Table 7 lists the required fields of the INVITE request sent from the SPS 106 to the DGW 110x.
Table 7 Parameter Usage Request-UneContains the method (a.p., INVfTE), Request-URI
using the gateway from the top of the unused contact Ilst and protaool version To Content copied from the original request message From Content copied from the original request message Call-ID Content copied from the original request message Csaq Content copied from the original request message Via Add the NS URL to the top Record Route Request-URI of the NS
The SPS 106 may receive a 100 trying response (see FIG. 3, step "h") or a 180 ringing response from the DGW 110a (See FIG. 3, step ~i~). Table 8 lists the required fields of the 180 ringing response.
Table 8 Parameter Usage Status-LineStatus Code =1130, Reason phrase and protocol version To Same as the original INVITE request plus tag From Same as the INVITE request Gent to the Egress Gateway Call-ID Same as the INVITE request sent to the Egress Gateway Cseq . Same as the INVITE request sent to the Egress Gateway V-~a Same as the INVITE request sent to the Egress Gateway After receiving the 180 ringing response from the DGW 110a, the SPS 106 removes itself from the top of the Via field, restarts the invite User Agent (UA) timer if it exists, and forwards the 180 ringing response to the ingress gateway (See FIG.
3, step "j"). The response message is sent to the address indicated in the Via header field.
Table 9 lists the required message elements.
Table 9 Parameter Usage Stalus LineContent copied from the 180 response received from the gateway To Content copied from the 1B0 response received from the gateway From Content copied from the 180 response received from the gateway Content copied from the 180 response received from the gateway Cseq Content copied from the 180 response received from the gateway Via Content copied from the 180 response received with the remove! of the NS URL.
The SPS receives an INVITE response (!.e., 200 OK response) from the DGW
110a (See FiG. 3, step "k"). Table 10 lists the required fields in the INVITE
message.
Table 10 Parameter Usage Status une Status Code = 200, Reason phrase and protocol version To Same as tho original INVITE request plus tag From game as the INVt'fE request sent to the Egress Gateway Call-ID Same as the INVITE request sent to the Egress Gateway Cseq Same as the INVITE request sent to the Egress Gateway Record RouteRequest-URI of the NS
Contact The reachable address of the Egress Gateway After receiving the 200 OK response from the DGW 110x, the SPS 106 performs the following steps: (1 ) cancels the invite UA timer, if it exists; (2) removes the SPS
URL from the Topmost Via Header (TMVH) field: (3) adds the next hop's Request URI
at the top of the record-route header field when either of the following conditions are met: a) there is no contact header field in the 200 OK response, or b) the SPS
URL is on the top entry of the record-route header field; (4) counts the number of responses sent by the SPS 106; and (5) the SPS 106 starts the ACK timer. The SPS
106 forwards the INVITE response (i.e., 200 OK response) to the ingress gateway (See FIG. 3, step "1"). Table 11 lists the required headers in the INVITE response.
Table 11 Parameter Usage Status-Lin~Status Code = 200, Reason phrase and protocol version To Same as the original INVITE request plus to From Same as the INVITE request sent to the Egress Gateway Call-ID Same 8s the INVfTE request sent to the Egress Gateway Cseq Same as the INVITE request sent to the Egress Gateway Via Content from tho INVITE request sent to the Egress GateWey Record RouteRequest-URI of the NS
Contact The reachabie.address of the Egress Gateway The SPS 108 receives an ACK response from the ingress gateway and stops the ACK timer. The SPS 106 counts the number of AGK response messages received by the SPS 106. Table 12 lists the required headers of the ACK response (See Fig.
3, step ~m~).
Table 12 Parameter Usage Request-LineContains method (e.g., ACfC~, Request-URt of the NS and protocol version To Same as the original INVITE plus the tag From Same as the original INVffE
Call-ID Same as the original INVITE
Cseq Same sequence number as the original INVITE
Via ~ originated The received ACK response may contain a route header field. The SPS 106 either proxies the ACK response using the address in the route header or uses the address in the "To" header to determine whether to proxy the ACK response or consume the ACK response. The ACK response will be consumed when the "To"
header address is equal to the SPS address, and no route header exists in the ACK
response. When the SPS 106 determines that the ACK response should be proxled, the SPS 108 perForms the following: (1 ) the SPS 108 adds the ACK's address to the top of the Via field; (2) the SPS 106 removes the top address from the route header field;
(3) the Request-URI is set to the address located at the top of the route header field;
and (4) the ACK message is forwarded to the DGW 110a based on the top address in the route header field if it exists or based on the call context's DGW
information (See FIG. 3, step °n"). Accordingly, the DGW 110a is selected as the available gateway for completing the call. If the DGW 110a is determined to be unavailable, the same method outlined above is used to determine if DGW 110b is available. If neither DGW
is available, a message is sent to the SUA 102 that the call cannot be completed.
Table 13 lists the parameters of the ACK request message sent to the DGW 110a.
Table 13 Parameter Request-LineContains method (e.g., ACK), Request-URI
is copied from the top list of Route hcadx field and protocol version To Content copied from the ACK received from the Ingress Gateway From Content copied from the ACK received from the Ingress Gateway Call-ID Content copied from the ACK received from the Ingress Gateway Content copied from the ACK received from the Ingress Gateway UA originated with the NS URL added to the top of Via field In another preferred method, a DGW is selected using a ping method. In this embodiment, gateway availability is determined by sending at least one packet to each destination gateway to ascertain whether the destination gateway is available, or in-service. Accordingly, if the destination gateway is in-service, it transmits an ACK
message. If art ACK message is not received after a predetermined period of time, the DGW is determined to be unavailable. The ping method preferably queries each destination gateway one-by-one and updates a gateway information table by recording the status of each gateway. For example, if the ACK message is received, the DGW is then checked to determine if it is available. If it is available, its address is stored in a gateway information table, and the process repeats for the next DGW.
FIG. 4 is a flowchart illustrating the methodology of an alternate embodiment of the present invention, i.e., the ping method. A counter is initialized at step 800 to indicate the currently selected destination gateway from the routing list (i.e., i=1 to the number of gateways in the routing list). In step 802, a message is transmitted from a server (e.g. proxy server, redirect server) to the ith destination gateway for the purpose of obtaining a response. In step 804 the server awaits a response from the ith destination gateway. Step 806 is a determination step to determine whether a response was received from the ith destination gateway. If a response is not received within a predetermined amount of time, the process continues at step 808 where it is determined whether there are additional destination gateways to check from the routing list. If not, the process terminates at step 810. Otherwise, the counter is incremented to select a succeeding destination gateway from the routing list at step 812.
Steps 802-806 are then repeated to check the response and/or availability of the succeeding (i.e.
ith + 1 ) destination gateway from the routing list. if It is determined at step 806 that a response is received within the predetermined time, the process continues to step 814 where it is then further determined whether the responding destination gateway is available or not. If the destination gateway is not available, the process returns to step 808 to determine whether there are additional destination gateways to check from the routing list. If so, steps 802-806 are repeated for the succeeding destination gateway.
Otherwise, if it is determined at step 814 that the responding destination gateway is available, the process continues at step 816 where the address of the available destination gateway is stored in a gateway Infomlation table. The process returns to step 808 to determine if there are additional destination gateways to be checked in the routing list.
What has been described herein is merely illustrative of the application of the principles of the present Invention. For example, the functions described above for operating the present Invention are for illustration purposes only. Other arrangements and methods may be implemented by those sia'lled in the art without departing from the scope and spirit of the invention.
Accordingly, in order for IP based telephony services to become broadly accepted by users of traditional telephones, it is necessary to interface the IP telephony network with the existing PSTN and with private PBX phone networks. To permit this mode of operation, a packet-based network, such as the Internet, must intertace directly with public telephone networks and operate as a bridge between originating and destination switches of such networks.
Media streams which originate from a public network must be capable of being transported through the packet-switched IP network and terminate at the same or different public network. This type of interfacing is pertormed by gateways which interface the signaling and bearer paths between the two networks. Therefore, Internet gateways perform code and protocol conversion between two otherwise incompatible networks to provide links necessary to send packets between the two different networks and thus make network-to-network connections possible. To assure overall system reliability it is crucial that the gateways are reliable and their availability, especially destination or egress gateways, be monitored for quickly and efficiently selecting an available gateway.
SUMMARY Of THE INVENTION
In accordance with the principles of the invention, a method and system are provided by which an egress (i.e., destination) gateway is dynamically selected to establish a communication session over a path supported at least in part by an IP
telephony network and 9 PSTN, PBX or other network. A redirect server (RS) in concert with a network management system (NMS) employs a gateway selection methodology which includes recording egress gateways which are not available due to several reasons, such as having timed out, or having a malfunction, i.e..
failure status.
In one embodiment of the present invention, a method is provided for dynamically selecting an egress gateway to allow 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 !P telephony network indudes a plurality of ingress and egress gateways, at least one Session Initiation Protocol (SIP) proxy server (SPS) and at least one redirect server (RS). A dynamic gateway selection (DGS) feature is always active and is typically invoked whenever a source user agent (SUA) initiates a call attempt by sending a session participation request to the SPS.
The preferred method generally includes the steps of: receivinfl a call setup request at the SPS from the SUA. The SpS forwards the request to the RS to obtain information of destination gateways. The RS responds to the SIP session participation request with either a redirection response or a request failure response. The RS
redirection response includes a routing list. The routing list is a list of egress (1e., destination) gateways that are determined to be in-service. Upon receipt of a redirection response from the RS, the SPS proxies the session participation request to a first destination gateway in the routing list. Otherwise, the RS returns a failuro response which is sent to the SUA. The failure response is an indication that there are no destination gateways having an in-service status.
When the SPS proxies the request to a destination gateway, the SPS waits for a final response from the selected destination gateway. The SPS will either receive a final response or time-out. When the SPS receives a final response from the destination gateway, the SPS proxies the final response to tfie SUA, awaits an acknowledgment and proxies the acknowledgment. Otherwise, when thA SPS times-out waiting for a final response from the destination gateway, the SPS re-sends the request a predetermined number of times. If the SPS times-out for a final time, the SPS
sends the session participation request to the next destination gateway in the routing list provided by the RS.
The process of sending a request a predetermined number of times is repeated for the next destination gateway iA the routing list until one of the following occurs: (1 ) a success response is returned; (2) the SPS times-out waiting for a final response, as described above with respect to the first destination gateway in the routing list; (3) the SPS receives an unsuccessful final, non-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 of the destination gateway failure.
In case of the second to fourth situations, the SPS sends the session participation request 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 as an out-of service destination gateway in the RS
and is dynamically removed from the routing list. Therefore, subsequent requests are not sent to destination gateways which are recorded as out-of service destination gateways in the RS until after a predetermined amount of time. After the predetermined amount of time has elapsed, the RS automatically recovers failed or out-of service pathways and issues a report to a network management system (NMS) indicating that the destination gateway is back in service. Table structures, stored within the RS, are updated on a real-time basis when it is determined that a gateway is out-of service or back in-service. When the session participation request has been sent to all destination .gateways and no successful response is received, the SPS returns a final response to the originating agent or calling party indicating that a call cannot be made.
In an alternative method, availability of destination gateways is determined using a ping method. In this method, gateway availability is determined by sending at least one packet to each destination gateway to ascertain whether the destination gateway is available, or in-service. If the destination gateway is in-service, it transmits an ACK
message. If an ACK message is not received after a predetermined period of time, the destination gateway (DGW) is determined to be unavailable. The ping method preferably pueries each destination gateway one-by-on~ and updates gateway information tables by recording the status of each destination gateway.
The present invention thereby provides several functions, including: (i ) dynamic detection of failed and unavailable gateways; (2) dynamic removal of failed and unavailable gateways) from a routing list, gateway information table, etc., after a predetermined period of time; and (3) automatic recovery of failed and unavailable gateways by updating gateway status tables after a predetermined period of time.
Various preferred embodiments are described herein with reference to the accompanying drawings, in which:
FIG. 1 is a block diagram of a preferred embodiment of the present invention;
FIG. 2 is a flowchart illustrating signaling and call setup procedures according to the embodiment of F1C3.1;
FIG. 3 is a call flow diagram illustrating the signaling and call setup procedures according to the embodiment of FIG. 1; and FIG. 4 is a flowchart illustrating an alternate embodiment of the present invention.
DETAILEQ DESCRIPTION OF THE PREFI~I~tRED EMBODIMENTS
Prefer-ed embodiments of the present invention will now be described with reference to the figures where like reference numbers indicate identical or similar elements. It will be apparent to persons skilled in the relevant art that the present invention can operate on many different types of networks without departing from the scope of the present invention. In the preferred embodiments described herein, the 1P
telephony network is preferably the Internet. Other examples of networks which could be used include leased lines, frame delay, 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 a PSTN, PBX or other network. The method further determines the status of a destination gatewgy, particularly, as being either in-service or out-of service, and automatically brings a destination gateway back into service from an out-of service state after a predetermined amount of time.
Referring now to the drawings, and first to FIG.1, a system according to a preferred embodiment of the present invention is designated generally by reference numeral 10. System 10 is a telephony network system and includes a first public switched telephone network (PSTN) 114a which interfaces to an IP telephony network or Internet 112_ The Internet 112 is further interFaced to a second PSTN 114b.
The first PSTN 114a includes a source user agent (SUA) 102, i.e.. originating agent, which originates a session participation request. The second PSTN 114b indudes a called party destination user agent (DUA 103). The Internet 112 indudes a redirect server (RS) 104, an SIP proxy server (SPS) 106, a Network Management System (NMS) 108, and destination gateways (DGWs) 110a, 110b. While only two DGWs are shown, one of ordinary skill in the art will recognize that additional DGWs may be provided. The RS
104 supports a gateway management function which tracks the status of the DGWs.
The NMS 108 receives and stores all status changes regarding DGWs 110a, 110b.
Status changes are reported to the NMS 108 by the RS 104 via the SPS 106. SPS
acts as both a server and client for the purpose of making requests on behalf of other clients. SPS 106 provides proxy server and gateway resource management functions.
SPS 106 may be a SIP proxy server or an H.323 gatekeeper.
The method of the present invention (i.e., dynamic gateway selection (DGS) and removal) is performed by the SPS 106 and RS 104 in context with the NMS 108 in order to allow calls to be routed to one of the DGWs 110a , 110b. The dynamic gateway selection and removal feature is particularly invoked upon receipt by the RS
104 of a session participation request. The SUA 102 initiates a call attempt to transmit the 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
114b. PSTN 114a and 114b are bridged via the Internet 112.
FIG. 2 is a flowchart illustrating the call routing logic for establishing a communication session in accordance with the methodology of the present invention.
At step 702, a user initiates a call attempt by sending a session participation request (1e., an INVITE request) to the SPS 106. When the INVITE request is an initial request, tha SPS 106 forwards the initial INVITE request to the RS 104 for routing instructions at step 704. At step 705, it is determined whether there is et least one DGW that can satisfy the request. If so, at step 706, the RS 104 responds to the SPS
106 query with a routing list, Le., a list of candidate DGWs that can handle the call. The RS 104 supplies the routing list from a gateway information table stored therein.
In the event the RS 104 determines that there are no DGWs that can satisfy the INVITE request, at step 705, a request failure response is returned to the SUA
102, at step 707. Upon receiving the routing list, the SPS 106 proxies the INVITE
request to one of the DGWs 110a, 110b. At Step 708, the SPS 106 selects the first DGW
110a in the routing list to determine Its serviceability and/or availability status.
Steps 710 and 712 determine whether the currently selected DGW 110a from the routing list is in a failure state or has timed out. Specifically, at step 710, a determination is made concerning whether the DGW 110a returns a failure response (i.e., out-of service response). If there is a failure response at step 710, the SPS 106 reports the gateway failure to the RS 104 at step 714. The RS 104 marks the selected~DGW 110a as an out-of-service destination gateway in a gateway information table stored in the RS 104, at step 716.
In addition, the SPS 106 sends a message, (i.e., Simple Network Management Protocol (SNMP) trap), to the NMS 108 indicating a destination gateway failure. The SPS 106 then selects the next DGW 110b in the routing list, at step 718.
Control then returns to step 710 to determine the availability of the next selected DGW
110b; that is, whether the next selected gateway 110b is in a failure state or has timed out.
If the next selected DGW 110b returns either a failure response at step 710, or times-out at step 712, then steps 714-718 are repeated. In short, the process of selecting a gateway from the routing list and determining whether it is in a failure state or has timed out is repeated until a bGW Is found from the routing list which accepts a call with a success response at step 720. When a success response is received, the SPS
10fi forwards the response to the calling user SUA 102 at step 722. The media stream for the call is then set up at step 724 to establish a communication link between the SUA
102 and DUA 103.
FIG. 3 is a call routing flow diagram illustrating in greater detail the call routing logic procedure described above with reference to FIG. 2. Table 1 below lists the INVITE required parameter fields in the preferred embodiment when a SUA 102 Initiates a call attempt by sending a session participation request (i.e., an INVITE
request) to the SPS 10fi (See FlG.I, item 1 and FIG. 3, step "a").
Table 1 Parameter Usage Request-LineContains the method (e.g., INVITE), Request Uniform Resource Ident'rtier (1e., Request-URI) of the SPS and protocol version To Contains the address of the recipient of the request From Contains the address of the initiator of the request Call-ID ~ Uniquely identifies the invitation Cseq Contains the request method and a decimal sequence number chosen by the requesting client, unique within a stn le value of the Call-ID
Via Indicates the path taken by the request so far The SIP INVITE is addressed to the called party DUA 103 at a proxy address at the SPS 106. The SIP INVITE specifies the real IP address of the DUA 103. Upon receipt of the SIP INVITE, the SPS 106 sends a 100 trying message to the ingress or origination gateway (FIG. 3, step "b"). Table 2 lists the mandatory fields associated with the 100 trying response message in the preferred embodiment.
Table 2 Parameter Usage Status-LineStatus Code =100, Reason phrase and protocol VerSiOn To Content copied from the original request message From Content copied from the original request mocs~ge Call-ID Content copies from tho original request message Cseq Content copies from the original request message Via Indicates the path taken by the request so far. Add the received-tag parameter if the previous ho address is ink in the via header field The SPS 106 counts the number of INVITE requests received. When a received request message does not contain a route header field, it is determined to be an initial INVITE request message. In such a case, the SPS 106 performs the following steps:
(1 ) if a Topmost Via Header ('TVH) source address is incorrect, adds a "Received"
parameter (or replaces the existing one if there is one) with the source package to the Via header field inserted by the previous hop; (2) generates an internal Call-ID; or (3) forwards the requested message to the RS 104 (See FIG. 1, item 2 and FIG. 3, step 'c'). Table 3 lists the required fields in the RS INVITE request message.
Table 3 Parameter Usage Status-Llne Content copied from the original request message To Content copied hom the original request message From Content copied from the original request message Call-ID Internally generated Call-I
Cseq Content copied from the original request message Vi8 Add the r~eoe'rved tag In response to receiving the RS INVITE request message from the SPS 106 , the RS 104 performs the following: (1) counts the number of INVITE messages received;
(2) determines that the user portion of 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;
and (3) queries a Network Control SysternlData Access Point (i.e., NCS/DAP) to obtain routing information (FIG. 3, step °d"). Routyng information, including a routing list of prospective DGWs, is then sent from the NCS/DAP to the RS 104 (FIG. 3, step "e").
The routing information is used to update the gateway information table stored in RS
104_ The gateway information table is subsequently used to create an updated routing list.
For example, when a gateway address is marked as out-of service in the gateway information table stored in RS 104 and its associated time value is zero 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 greater than the current absolute RS time, 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 the gateway address is marked as in-service in the gateway information table. The RS 704 also sends a message, i.e., the Simple Network Management Protocol (SNMP) trap, to the NMS 108 indicating that the DGW is in-service. If there is only one gateway in the routing list, the RS 104 will send a 302 response message back to the SPS 106 (See FIG. 1, item 3 and FIG. 3, step "f"). The RS 104 increments a eounterwhich Counts the number of 3~oc messages sent. Table 4 lists the required fields in the 3xx (302 in the present case) response message and an ~exampte of the contact address list.
T2~ble 4 Parameter Usage Status-LineStatus Code = 302, Reason phrase and protocol version To Content copied from the Original INVffE request From Content capIed from the Original INVITE request Call-ID Content copied from the Original INVITE request Cseq Content copied from the Original INVITE request Via Content copied from the Original INVITE requaat Contact Multiple gateway addresses Table 5 Ilsts the required fields in the SNMP trap message to the NMS.
Table 5 Parameter Usage Protocol Indicates that this is a Trap PD
Data Unit (PDU) Type Enterprise Identifies the network-management subsystem that generated the trap, Its value is taken from sysobjectlD In the system Group Agent-addr The IP address of the object generating the tra Generic-trap6 = enterpriseSpecific. This value signifies that the sending protocol entity recognizes that some enterprise-specific event has occurred.
The specifi~trap field indicates the type of trap Specfic-trapA code that indicate more specifically the nature of the trap Time-stamp The time between the last (re)initialization of the network entity that issued the trap and the generation of the trap Variable The address of the gateway that returned the 5xx bindings responss and status (In-service) In the case where there is more than one gateway in the routing list, the RS
sends a 300 response message, instead of a 302 response message for a single gateway, back to the SPS 106. For a 300 response, the RS 104 also counts the number of 3~ot responses sent. Table 6 lists the required fields in the 300 response message and an example of the contact address list.
Tablo 6 Parameter Usage Status-LineStatus Code = 300, Reason phrase and protocol version To Same as the original INVITE
From Content copied from the Original INVITE request Cat!-ID Content copied from the Original INVITE request Cseq Content copied from the Original INVITE request Via Content copied fr~nm the Original INVITE request Contact Multiple reachable addresses The SPS 106 counts the number of routing responses received from tho RS 104.
The SPS 106 sends an INVITE to the first DGW 110x, and inserts the °user-phone°
header in each contact list address (See FIG. 1, item 4 and FIG. 3, step ~g").
Table 7 lists the required fields of the INVITE request sent from the SPS 106 to the DGW 110x.
Table 7 Parameter Usage Request-UneContains the method (a.p., INVfTE), Request-URI
using the gateway from the top of the unused contact Ilst and protaool version To Content copied from the original request message From Content copied from the original request message Call-ID Content copied from the original request message Csaq Content copied from the original request message Via Add the NS URL to the top Record Route Request-URI of the NS
The SPS 106 may receive a 100 trying response (see FIG. 3, step "h") or a 180 ringing response from the DGW 110a (See FIG. 3, step ~i~). Table 8 lists the required fields of the 180 ringing response.
Table 8 Parameter Usage Status-LineStatus Code =1130, Reason phrase and protocol version To Same as the original INVITE request plus tag From Same as the INVITE request Gent to the Egress Gateway Call-ID Same as the INVITE request sent to the Egress Gateway Cseq . Same as the INVITE request sent to the Egress Gateway V-~a Same as the INVITE request sent to the Egress Gateway After receiving the 180 ringing response from the DGW 110a, the SPS 106 removes itself from the top of the Via field, restarts the invite User Agent (UA) timer if it exists, and forwards the 180 ringing response to the ingress gateway (See FIG.
3, step "j"). The response message is sent to the address indicated in the Via header field.
Table 9 lists the required message elements.
Table 9 Parameter Usage Stalus LineContent copied from the 180 response received from the gateway To Content copied from the 1B0 response received from the gateway From Content copied from the 180 response received from the gateway Content copied from the 180 response received from the gateway Cseq Content copied from the 180 response received from the gateway Via Content copied from the 180 response received with the remove! of the NS URL.
The SPS receives an INVITE response (!.e., 200 OK response) from the DGW
110a (See FiG. 3, step "k"). Table 10 lists the required fields in the INVITE
message.
Table 10 Parameter Usage Status une Status Code = 200, Reason phrase and protocol version To Same as tho original INVITE request plus tag From game as the INVt'fE request sent to the Egress Gateway Call-ID Same as the INVITE request sent to the Egress Gateway Cseq Same as the INVITE request sent to the Egress Gateway Record RouteRequest-URI of the NS
Contact The reachable address of the Egress Gateway After receiving the 200 OK response from the DGW 110x, the SPS 106 performs the following steps: (1 ) cancels the invite UA timer, if it exists; (2) removes the SPS
URL from the Topmost Via Header (TMVH) field: (3) adds the next hop's Request URI
at the top of the record-route header field when either of the following conditions are met: a) there is no contact header field in the 200 OK response, or b) the SPS
URL is on the top entry of the record-route header field; (4) counts the number of responses sent by the SPS 106; and (5) the SPS 106 starts the ACK timer. The SPS
106 forwards the INVITE response (i.e., 200 OK response) to the ingress gateway (See FIG. 3, step "1"). Table 11 lists the required headers in the INVITE response.
Table 11 Parameter Usage Status-Lin~Status Code = 200, Reason phrase and protocol version To Same as the original INVITE request plus to From Same as the INVITE request sent to the Egress Gateway Call-ID Same 8s the INVfTE request sent to the Egress Gateway Cseq Same as the INVITE request sent to the Egress Gateway Via Content from tho INVITE request sent to the Egress GateWey Record RouteRequest-URI of the NS
Contact The reachabie.address of the Egress Gateway The SPS 108 receives an ACK response from the ingress gateway and stops the ACK timer. The SPS 106 counts the number of AGK response messages received by the SPS 106. Table 12 lists the required headers of the ACK response (See Fig.
3, step ~m~).
Table 12 Parameter Usage Request-LineContains method (e.g., ACfC~, Request-URt of the NS and protocol version To Same as the original INVITE plus the tag From Same as the original INVffE
Call-ID Same as the original INVITE
Cseq Same sequence number as the original INVITE
Via ~ originated The received ACK response may contain a route header field. The SPS 106 either proxies the ACK response using the address in the route header or uses the address in the "To" header to determine whether to proxy the ACK response or consume the ACK response. The ACK response will be consumed when the "To"
header address is equal to the SPS address, and no route header exists in the ACK
response. When the SPS 106 determines that the ACK response should be proxled, the SPS 108 perForms the following: (1 ) the SPS 108 adds the ACK's address to the top of the Via field; (2) the SPS 106 removes the top address from the route header field;
(3) the Request-URI is set to the address located at the top of the route header field;
and (4) the ACK message is forwarded to the DGW 110a based on the top address in the route header field if it exists or based on the call context's DGW
information (See FIG. 3, step °n"). Accordingly, the DGW 110a is selected as the available gateway for completing the call. If the DGW 110a is determined to be unavailable, the same method outlined above is used to determine if DGW 110b is available. If neither DGW
is available, a message is sent to the SUA 102 that the call cannot be completed.
Table 13 lists the parameters of the ACK request message sent to the DGW 110a.
Table 13 Parameter Request-LineContains method (e.g., ACK), Request-URI
is copied from the top list of Route hcadx field and protocol version To Content copied from the ACK received from the Ingress Gateway From Content copied from the ACK received from the Ingress Gateway Call-ID Content copied from the ACK received from the Ingress Gateway Content copied from the ACK received from the Ingress Gateway UA originated with the NS URL added to the top of Via field In another preferred method, a DGW is selected using a ping method. In this embodiment, gateway availability is determined by sending at least one packet to each destination gateway to ascertain whether the destination gateway is available, or in-service. Accordingly, if the destination gateway is in-service, it transmits an ACK
message. If art ACK message is not received after a predetermined period of time, the DGW is determined to be unavailable. The ping method preferably queries each destination gateway one-by-one and updates a gateway information table by recording the status of each gateway. For example, if the ACK message is received, the DGW is then checked to determine if it is available. If it is available, its address is stored in a gateway information table, and the process repeats for the next DGW.
FIG. 4 is a flowchart illustrating the methodology of an alternate embodiment of the present invention, i.e., the ping method. A counter is initialized at step 800 to indicate the currently selected destination gateway from the routing list (i.e., i=1 to the number of gateways in the routing list). In step 802, a message is transmitted from a server (e.g. proxy server, redirect server) to the ith destination gateway for the purpose of obtaining a response. In step 804 the server awaits a response from the ith destination gateway. Step 806 is a determination step to determine whether a response was received from the ith destination gateway. If a response is not received within a predetermined amount of time, the process continues at step 808 where it is determined whether there are additional destination gateways to check from the routing list. If not, the process terminates at step 810. Otherwise, the counter is incremented to select a succeeding destination gateway from the routing list at step 812.
Steps 802-806 are then repeated to check the response and/or availability of the succeeding (i.e.
ith + 1 ) destination gateway from the routing list. if It is determined at step 806 that a response is received within the predetermined time, the process continues to step 814 where it is then further determined whether the responding destination gateway is available or not. If the destination gateway is not available, the process returns to step 808 to determine whether there are additional destination gateways to check from the routing list. If so, steps 802-806 are repeated for the succeeding destination gateway.
Otherwise, if it is determined at step 814 that the responding destination gateway is available, the process continues at step 816 where the address of the available destination gateway is stored in a gateway Infomlation table. The process returns to step 808 to determine if there are additional destination gateways to be checked in the routing list.
What has been described herein is merely illustrative of the application of the principles of the present Invention. For example, the functions described above for operating the present Invention are for illustration purposes only. Other arrangements and methods may be implemented by those sia'lled in the art without departing from the scope and spirit of the invention.
Claims (20)
1. A method for routing calls to a destination gateway to establish a communication session call in a telecommunications network over a path supported at least in part by a telephone network and an IP network, said IP network including a plurality of ingress and destination gateways, at least one proxy server, and at least one redirect server (RS). said method comprising the steps of:
a) receiving a call setup request at the at least one proxy server from a source user agent;
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 said routing information or a request failure response;
d) proxying the call setup request by the at least one proxy server to a destination gateway selected from said routing information upon receiving the routing information from the redirect server;
e) upon proxying the call setup request by the at least one proxy server to the selected destination gateway, waiting for a response at the at least one proxy server from the selected destination gateway;
f) upon said at least one proxy server receiving the response from the selected destination gateway within a predetermined time, establishing a communication session using said selected destination gateway; and g) if the response is n4t received within the predetermined time, sending the call setup request to a succeeding destination gateway selected from~the routing information.
a) receiving a call setup request at the at least one proxy server from a source user agent;
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 said routing information or a request failure response;
d) proxying the call setup request by the at least one proxy server to a destination gateway selected from said routing information upon receiving the routing information from the redirect server;
e) upon proxying the call setup request by the at least one proxy server to the selected destination gateway, waiting for a response at the at least one proxy server from the selected destination gateway;
f) upon said at least one proxy server receiving the response from the selected destination gateway within a predetermined time, establishing a communication session using said selected destination gateway; and g) if the response is n4t received within the predetermined time, sending the call setup request to a succeeding destination gateway selected from~the routing information.
2. The method as claimed in claim 1, further comprising repeating steps (d) to (g) until a destination gateway is determined to be available for establishing said communication session or until all destination gateways from said routing information have been determined to be unavailable.
3. The method as claimed in claim 1, further comprising the step of recording a destination gateway status as out-of service if the response from said destination gateway is not received within said predetermined time.
4. The method as claimed in claim 3, wherein said step of recording records said destination gateway status as out-of-service in a gateway infomlation table stored within the RS.
5. The method as claimed in claim 1, wherein said step of receiving a call setup request at the at least one proxy server from a source user agent includes the step of addressing said call setup request to a proxy address of the at least one proxy server.
6. The method as claimed in claim 1, wherein said step of receiving a call setup request at the at least one proxy server from a source user agent includes the step of counting a number of received requests subsequent to said cast setup request at the at least one proxy server.
7. The method as claimed in claim 1, wherein the at least one proxy server comprises a Session Initiation Protocol (SIP) proxy server.
8. The method as claimed in claim 1, wherein the at feast one proxy server comprises an H.323 gatekeeper.
9. The method as claimed in claim 1, wherein said step of responding to the forwarded call setup request from said at least one proxy server received at the RS
includes determining the status of a group of destination gateways.
includes determining the status of a group of destination gateways.
28 100 The method as claimed in claim 9, wherein the status of each of said group or destination gateway is one of in-service and out-of-service.
11. The method as claimed in claim 10, wherein if the destination gateway status is recorded as out-of service in a gateway information table and its associated time value is greater than a current absolute RS time, the gateway address is not added to a routing list of said routing information.
12. The method as claimed in claim 10, wherein if the destination gateway status is recorded as out-of service in a gateway information table and its associated lime value is less than or equal to the current absolute RS time, the gateway address is added to a routing list of said routing information and recorded as in-service.
13. The method as claimed in claim 10, further including the step of sending a message from the RS to a network manager to record the status of a destination gateway.
140 The method as claimed in claim 1, further comprising the steps of forwarding a request failure response to the source user agent upon receiving the request failure response from the at least one proxy server, and terminating the communication session.
150 The method as claimed in claim 1, further comprising the step of re-sending the call setup request to the selected destination gateway a predetermined number of times when the response is not received within the predetermined time.
160 A system for allowing a call to be completed in a communication session between a calling party and a called party, which comprises:
a first telephony system including at least one service user agent (SUA);
a second telephony 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 interfacing said IP network to said first telephony system;
a plurality of egress gateways for interfacing said IP network to said second telephony system;
an IP telephony proxy server for selecting one of said plurality of egress gateways for completing said call;
an IP redirect server for providing routing information to said IP telephony proxy server; and a network management system for receiving and storing status changes of destination gateways, said network management system being in communication with said IP redirect server.
a first telephony system including at least one service user agent (SUA);
a second telephony 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 interfacing said IP network to said first telephony system;
a plurality of egress gateways for interfacing said IP network to said second telephony system;
an IP telephony proxy server for selecting one of said plurality of egress gateways for completing said call;
an IP redirect server for providing routing information to said IP telephony proxy server; and a network management system for receiving and storing status changes of destination gateways, said network management system being in communication with said IP redirect server.
170 The system as claimed in claim 16, wherein the IP telephony proxy server is a Session Initiation Protocol (SIP) proxy server.
180 The system as claimed in claim 18, 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, said method comprising the steps of:
a) transmitting a message to one of said plurality of destination gateways from a server to ascertain an availability status of said one of said plurality of destination gateways;
b) waiting for an acknowledge response from said one of said plurality of destination gateways for a predetermined period of time;
c) determining if said one of said plurality of destination gateways is available if said acknowledge response is received within said predetermined period of time: and d) transmitting said message to a succeeding gateway of said plurality of destination gateways.
a) transmitting a message to one of said plurality of destination gateways from a server to ascertain an availability status of said one of said plurality of destination gateways;
b) waiting for an acknowledge response from said one of said plurality of destination gateways for a predetermined period of time;
c) determining if said one of said plurality of destination gateways is available if said acknowledge response is received within said predetermined period of time: and d) transmitting said message to a succeeding gateway of said plurality of destination gateways.
20. The method as claimed in claim 19, further comprising repeating steps (b) to (d) until the availability status of each of said plurality of destination gateways has been determined.
210 The method according to claim 19, wherein if said acknowledge response is not received within a predetermined period of time, said availability status of said destination gateway is said to be out-of service.
220 The method according to claim 19, wherein if said one of said plurality of destination gateways is determined to be available, then said availability status is determined to be in-service.
210 The method according to claim 19, wherein if said acknowledge response is not received within a predetermined period of time, said availability status of said destination gateway is said to be out-of service.
220 The method according to claim 19, wherein if said one of said plurality of destination gateways is determined to be available, then said availability status is determined to be in-service.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/436,796 US7860114B1 (en) | 1999-11-08 | 1999-11-08 | Method and system for dynamic gateway selection in an IP telephony network |
| US09/436,796 | 1999-11-08 | ||
| PCT/US2000/041994 WO2001039444A1 (en) | 1999-11-08 | 2000-11-08 | Method and system for dynamic gateway selection in an ip telephony network |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2391037A1 true CA2391037A1 (en) | 2001-05-31 |
Family
ID=23733866
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002391037A Abandoned CA2391037A1 (en) | 1999-11-08 | 2000-11-08 | Method and system for dynamic gateway selection in an ip telephony network |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7860114B1 (en) |
| EP (1) | EP1230770A4 (en) |
| JP (1) | JP2003515969A (en) |
| CN (1) | CN1421081A (en) |
| AU (1) | AU4303601A (en) |
| BR (1) | BR0015413A (en) |
| CA (1) | CA2391037A1 (en) |
| MX (1) | MXPA02004607A (en) |
| WO (1) | WO2001039444A1 (en) |
Families Citing this family (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080005275A1 (en) * | 2000-06-02 | 2008-01-03 | Econnectix, Llc | Method and apparatus for managing location information in a network separate from the data to which the location information pertains |
| CN1317854C (en) * | 2002-04-20 | 2007-05-23 | 中兴通讯股份有限公司 | Method for detecting medium gateway controller and medium between-gateways link state |
| CN1295911C (en) * | 2003-01-30 | 2007-01-17 | 华为技术有限公司 | A routing method for IP telephone system |
| KR100602652B1 (en) * | 2004-02-13 | 2006-07-19 | 삼성전자주식회사 | Method for routing pass management of voice over internet protocol system and the same |
| CN100450123C (en) * | 2004-05-24 | 2009-01-07 | 中兴通讯股份有限公司 | Method for raising call completing rate between exchange |
| US7284148B2 (en) * | 2004-06-17 | 2007-10-16 | International Business Machines Corporation | Method and system for self-healing in routers |
| GB0610635D0 (en) * | 2006-05-30 | 2006-07-05 | Nokia Corp | Allocation of a call state control function to a subscriber |
| US8296839B2 (en) * | 2006-06-06 | 2012-10-23 | The Mitre Corporation | VPN discovery server |
| US8213295B2 (en) * | 2006-09-12 | 2012-07-03 | Qualcomm Incorporated | Transaction timeout handling in communication session management |
| CN101064965B (en) * | 2006-10-17 | 2010-04-21 | 华为技术有限公司 | Method, system and apparatus for reselecting the called user terminal in redirection service |
| US9054959B2 (en) * | 2006-10-30 | 2015-06-09 | Thomson Licensing | Method for indicating a service interruption source |
| US8542802B2 (en) | 2007-02-15 | 2013-09-24 | Global Tel*Link Corporation | System and method for three-way call detection |
| CN101115214B (en) * | 2007-08-15 | 2011-04-20 | 华为技术有限公司 | Method, equipment and system for intelligent call routing |
| DE602007013821D1 (en) | 2007-09-28 | 2011-05-19 | Ericsson Telefon Ab L M | TROUBLESHOOTING IN AN IP MULTIMEDIA SUBSYSTEM NETWORK |
| JP4881829B2 (en) * | 2007-10-03 | 2012-02-22 | 株式会社日立製作所 | Packet forwarding system |
| CN101217434B (en) * | 2008-01-14 | 2011-07-13 | 中兴通讯股份有限公司 | Access gateway state detecting method |
| CN101227748B (en) * | 2008-01-23 | 2012-05-23 | 中兴通讯股份有限公司 | Method for selecting access network gateway in microwave access global intercommunication wireless communication system |
| US8582560B2 (en) * | 2009-01-30 | 2013-11-12 | Level 3 Communications, Llc | System and method for routing calls associated with private dialing plans |
| US9225838B2 (en) | 2009-02-12 | 2015-12-29 | Value-Added Communications, Inc. | System and method for detecting three-way call circumvention attempts |
| CN101873238B (en) * | 2010-06-29 | 2015-06-03 | 中兴通讯股份有限公司 | Method for realizing association of calling control protocol and media control protocol |
| MY169842A (en) | 2011-11-24 | 2019-05-16 | Mimos Berhad | Dynamic gateway selection ip mobility |
| WO2015061938A1 (en) * | 2013-10-28 | 2015-05-07 | 华为技术有限公司 | Method, device and system for redirecting data service proxy |
| US9930088B1 (en) * | 2017-06-22 | 2018-03-27 | Global Tel*Link Corporation | Utilizing VoIP codec negotiation during a controlled environment call |
| CN110086685A (en) * | 2019-06-13 | 2019-08-02 | 深圳市友华通信技术有限公司 | Network recovery method based on the network terminal |
Family Cites Families (108)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU570439B2 (en) | 1983-03-28 | 1988-03-17 | Compression Labs, Inc. | A combined intraframe and interframe transform coding system |
| US5303286A (en) | 1991-03-29 | 1994-04-12 | Space Systems/Loral, Inc. | Wireless telephone/satellite roaming system |
| JPH04502991A (en) | 1988-11-14 | 1992-05-28 | データーポイント・コーポレーション | Local area network with dynamically selectable multioperability |
| US6067442A (en) | 1991-10-10 | 2000-05-23 | Globalstar L.P. | Satellite communications system having distributed user assignment and resource assignment with terrestrial gateways |
| US5434907A (en) | 1992-03-13 | 1995-07-18 | Allnet Communication Services Inc. | Voice mail notification system |
| US5353335A (en) | 1992-08-03 | 1994-10-04 | At&T Bell Laboratories | Multilingual prepaid telephone system |
| JP2693907B2 (en) * | 1993-12-27 | 1997-12-24 | 日本電気株式会社 | Static routing method |
| JP3434074B2 (en) | 1994-06-23 | 2003-08-04 | 富士通株式会社 | Multimedia communication equipment |
| US5634012A (en) | 1994-11-23 | 1997-05-27 | Xerox Corporation | System for controlling the distribution and use of digital works having a fee reporting mechanism |
| US6215858B1 (en) | 1994-12-05 | 2001-04-10 | Bell Atlantic Network Services, Inc. | Analog terminal internet access |
| US5732219A (en) | 1995-03-17 | 1998-03-24 | Vermeer Technologies, Inc. | Computer system and computer-implemented process for remote editing of computer files |
| GB2301260A (en) | 1995-05-26 | 1996-11-27 | Ibm | Voice mail system |
| US6094525A (en) | 1995-07-06 | 2000-07-25 | Novell, Inc. | Network addressing arrangement for backward compatible routing of an expanded address space |
| US5745556A (en) | 1995-09-22 | 1998-04-28 | At&T Corp. | Interactive and information data services telephone billing system |
| US5953504A (en) | 1995-10-10 | 1999-09-14 | Suntek Software Corporation | Public accessible terminal capable of opening an account for allowing access to the internet and E-mail by generating ID code and security code for users |
| US6243373B1 (en) | 1995-11-01 | 2001-06-05 | Telecom Internet Ltd. | Method and apparatus for implementing a computer network/internet telephone system |
| US5832221A (en) | 1995-12-29 | 1998-11-03 | At&T Corp | Universal message storage system |
| US5802510A (en) | 1995-12-29 | 1998-09-01 | At&T Corp | Universal directory service |
| US5826039A (en) | 1995-12-29 | 1998-10-20 | Lucent Technologies Inc. | Universal connection point for resources and communication unrelated to a physical endpoint |
| US5742763A (en) | 1995-12-29 | 1998-04-21 | At&T Corp. | Universal message delivery system for handles identifying network presences |
| US5768361A (en) | 1995-12-29 | 1998-06-16 | Mci Corporation | Flexible enhanced signaling subsystem for a telecommunications switch |
| US6084952A (en) | 1996-01-18 | 2000-07-04 | Pocketscience, Inc. | System and method for communicating electronic messages over a telephone network using acoustical coupling |
| US5956391A (en) | 1996-02-09 | 1999-09-21 | Telefonaktiebolaget Lm Ericsson | Billing in the internet |
| GB2310970A (en) | 1996-03-05 | 1997-09-10 | Ibm | Voice mail on the Internet |
| US6069890A (en) * | 1996-06-26 | 2000-05-30 | Bell Atlantic Network Services, Inc. | Internet telephone service |
| US6094578A (en) | 1996-07-10 | 2000-07-25 | American Pcs Communications, Llc | Gateway unit |
| US5859898A (en) | 1996-09-17 | 1999-01-12 | Nynex Science & Technology | Messaging architecture supporting digital and analog media |
| US5923659A (en) | 1996-09-20 | 1999-07-13 | Bell Atlantic Network Services, Inc. | Telecommunications network |
| US5907547A (en) | 1996-10-24 | 1999-05-25 | At&T Corp | System and method for establishing internet communications links |
| JP3455032B2 (en) | 1996-10-31 | 2003-10-06 | 株式会社日立製作所 | Communications system |
| US6233318B1 (en) | 1996-11-05 | 2001-05-15 | Comverse Network Systems, Inc. | System for accessing multimedia mailboxes and messages over the internet and via telephone |
| CA2217838C (en) | 1996-11-07 | 2003-07-29 | At&T Corp. | Wan-based voice gateway |
| US5999525A (en) | 1996-11-18 | 1999-12-07 | Mci Communications Corporation | Method for video telephony over a hybrid network |
| US5867494A (en) | 1996-11-18 | 1999-02-02 | Mci Communication Corporation | System, method and article of manufacture with integrated video conferencing billing in a communication system architecture |
| US6335927B1 (en) | 1996-11-18 | 2002-01-01 | Mci Communications Corporation | System and method for providing requested quality of service in a hybrid network |
| US5867495A (en) | 1996-11-18 | 1999-02-02 | Mci Communications Corporations | System, method and article of manufacture for communications utilizing calling, plans in a hybrid network |
| US5794039A (en) | 1996-12-18 | 1998-08-11 | Unisys Corp. | Method for abstracting messages of various protocols into objects for storage in a database |
| US6073160A (en) | 1996-12-18 | 2000-06-06 | Xerox Corporation | Document communications controller |
| US5883894A (en) * | 1996-12-30 | 1999-03-16 | 3Com Corporation | Shared auto-negotiation logic for multiple port network devices |
| US6064653A (en) | 1997-01-07 | 2000-05-16 | Bell Atlantic Network Services, Inc. | Internetwork gateway to gateway alternative communication |
| US6687221B1 (en) | 1997-02-21 | 2004-02-03 | Fujitsu Limited | Communication management control system, communication control unit therefor and computer program product |
| US5960416A (en) | 1997-02-27 | 1999-09-28 | Block; Robert S. | Real time subscriber billing at a subscriber location in an unstructured communication network |
| US6157648A (en) * | 1997-03-06 | 2000-12-05 | Bell Atlantic Network Services, Inc. | Network session management |
| US6137869A (en) | 1997-09-16 | 2000-10-24 | Bell Atlantic Network Services, Inc. | Network session management |
| US5889774A (en) | 1997-03-14 | 1999-03-30 | Efusion, Inc. | Method and apparatus for selecting an internet/PSTN changeover server for a packet based phone call |
| US6292479B1 (en) | 1997-03-19 | 2001-09-18 | Bell Atlantic Network Services, Inc. | Transport of caller identification information through diverse communication networks |
| US5930348A (en) * | 1997-03-20 | 1999-07-27 | Northern Telecom Limited | Dynamically controlled routing of calls in intelligent networks |
| US5951638A (en) | 1997-03-21 | 1999-09-14 | International Business Machines Corporation | Integrated multimedia messaging system |
| US6163536A (en) | 1997-06-11 | 2000-12-19 | International Business Machines Corporation | Communication system including a client controlled gateway for concurrent voice/data messaging with a data server |
| US5958005A (en) | 1997-07-17 | 1999-09-28 | Bell Atlantic Network Services, Inc. | Electronic mail security |
| US6151390A (en) | 1997-07-31 | 2000-11-21 | Cisco Technology, Inc. | Protocol conversion using channel associated signaling |
| US6295291B1 (en) | 1997-07-31 | 2001-09-25 | Nortel Networks Limited | Setup of new subscriber radiotelephone service using the internet |
| US6144667A (en) | 1997-08-07 | 2000-11-07 | At&T Corp. | Network-based method and apparatus for initiating and completing a telephone call via the internet |
| US6167042A (en) | 1997-09-16 | 2000-12-26 | Lucent Technologies Inc. | Communications between service providers and customer premises equipment |
| AU748468B2 (en) | 1997-09-16 | 2002-06-06 | Transnexus, Inc. | Internet telephony call routing engine |
| CA2216620C (en) | 1997-09-24 | 2002-06-25 | Bell Canada | Method and apparatus for dynamically routing calls in an intelligent network |
| NO326260B1 (en) | 1997-09-29 | 2008-10-27 | Ericsson Telefon Ab L M | Method of routing calls from a terminal in a first telecommunications network to a terminal in a second telecommunications network |
| US6134235A (en) | 1997-10-08 | 2000-10-17 | At&T Corp. | Pots/packet bridge |
| US6178181B1 (en) | 1997-12-01 | 2001-01-23 | Telefonaktiebolaget L M Ericsson (Publ) | Mapping function and method of transmitting signaling system 7(SS7) telecommunications messages over data networks |
| US6226364B1 (en) | 1997-12-08 | 2001-05-01 | Bellsouth Intellectual Property Management Corporation | Method and system for providing prepaid and credit-limited telephone services |
| US6201858B1 (en) | 1997-12-17 | 2001-03-13 | Nortel Networks Limited | Multiple terminal message indicator for a telecommunications network |
| US6118864A (en) | 1997-12-31 | 2000-09-12 | Carmel Connection, Inc. | System and method for providing communication on a wide area network |
| US6614780B2 (en) | 1998-01-02 | 2003-09-02 | Lucent Technologies Inc. | Internet calling apparatus and method |
| US6278707B1 (en) | 1998-01-07 | 2001-08-21 | Mci Communications Corporation | Platform for coupling a circuit-switched network to a data network |
| US6151629A (en) | 1998-03-02 | 2000-11-21 | Compaq Computer Corporation | Triggered remote dial-up for internet access |
| US6353614B1 (en) | 1998-03-05 | 2002-03-05 | 3Com Corporation | Method and protocol for distributed network address translation |
| US6188760B1 (en) | 1998-05-08 | 2001-02-13 | Cisco Technology, Inc. | Signaling state management system for packet network gateways |
| US6470008B1 (en) | 1998-07-09 | 2002-10-22 | Sprint Communications Company L.P. | Internet routing system |
| US6202081B1 (en) | 1998-07-21 | 2001-03-13 | 3Com Corporation | Method and protocol for synchronized transfer-window based firewall traversal |
| US6487283B2 (en) * | 1998-08-04 | 2002-11-26 | Transnexus, Inc. | Pricing center for internet protocol routed transactions |
| US6259914B1 (en) | 1998-08-07 | 2001-07-10 | Bellsouth Intellectual Property Corporation | Method and apparatus for implementing international wireless roaming |
| US6584093B1 (en) | 1998-08-25 | 2003-06-24 | Cisco Technology, Inc. | Method and apparatus for automatic inter-domain routing of calls |
| US6253249B1 (en) | 1998-08-31 | 2001-06-26 | Nortel Networks Limited | Method and devices for bridging data and telephone networks |
| US6404870B1 (en) * | 1998-09-14 | 2002-06-11 | Cisco Technology, Inc. | Method and apparatus for authorization based phone calls in packet switched networks |
| US6529499B1 (en) | 1998-09-22 | 2003-03-04 | Lucent Technologies Inc. | Method for providing quality of service for delay sensitive traffic over IP networks |
| US6570869B1 (en) | 1998-09-30 | 2003-05-27 | Cisco Technology, Inc. | Communicating voice over a packet-switching network |
| US6658022B1 (en) | 1998-09-30 | 2003-12-02 | Cisco Technology, Inc. | Signaling protocol for controlling voice calls in a packet switching network |
| US6393269B1 (en) | 1998-10-14 | 2002-05-21 | Openwave Systems Inc. | Signaling system and method for network-based pre-paid wireless telephone service |
| US6240449B1 (en) * | 1998-11-02 | 2001-05-29 | Nortel Networks Limited | Method and apparatus for automatic call setup in different network domains |
| US6161008A (en) | 1998-11-23 | 2000-12-12 | Nortel Networks Limited | Personal mobility and communication termination for users operating in a plurality of heterogeneous networks |
| US6463053B1 (en) | 1998-12-01 | 2002-10-08 | Nortel Networks Limited | Voice-and-fax-over IP dialing plan |
| US6519242B1 (en) | 1998-12-09 | 2003-02-11 | Nortel Networks Limited | Apparatus and method of PSTN based network roaming and SCP based subscriber management for internet telephony systems |
| US6333931B1 (en) | 1998-12-28 | 2001-12-25 | Cisco Technology, Inc. | Method and apparatus for interconnecting a circuit-switched telephony network and a packet-switched data network, and applications thereof |
| US6674745B1 (en) | 1998-12-31 | 2004-01-06 | 3Com Corporation | Method and system for mapping phone numbers to IP addresses |
| JP4051794B2 (en) | 1999-01-13 | 2008-02-27 | 富士通株式会社 | Voice gateway device and route selection method thereof |
| JP3689580B2 (en) * | 1999-01-29 | 2005-08-31 | 株式会社日立製作所 | Internet telephone connection method, bandwidth management device, and gatekeeper device |
| US6775269B1 (en) | 1999-03-30 | 2004-08-10 | Telecom Technologies, Inc. | Method and system for routing telephone calls between a public switched telephone network and an internet protocol network |
| US6631186B1 (en) | 1999-04-09 | 2003-10-07 | Sbc Technology Resources, Inc. | System and method for implementing and accessing call forwarding services |
| US6567399B1 (en) | 1999-05-05 | 2003-05-20 | 3Com Corporation | Hi-fidelity line card |
| US6240391B1 (en) | 1999-05-25 | 2001-05-29 | Lucent Technologies Inc. | Method and apparatus for assembling and presenting structured voicemail messages |
| JP4110671B2 (en) | 1999-05-27 | 2008-07-02 | 株式会社日立製作所 | Data transfer device |
| US6195697B1 (en) | 1999-06-02 | 2001-02-27 | Ac Properties B.V. | System, method and article of manufacture for providing a customer interface in a hybrid network |
| US6147975A (en) | 1999-06-02 | 2000-11-14 | Ac Properties B.V. | System, method and article of manufacture of a proactive threhold manager in a hybrid communication system architecture |
| US6081518A (en) | 1999-06-02 | 2000-06-27 | Anderson Consulting | System, method and article of manufacture for cross-location registration in a communication system architecture |
| US6842447B1 (en) | 1999-06-14 | 2005-01-11 | Mci, Inc. | Internet protocol transport of PSTN-to-PSTN telephony services |
| US6779032B1 (en) | 1999-07-01 | 2004-08-17 | International Business Machines Corporation | Method and system for optimally selecting a Telnet 3270 server in a TCP/IP network |
| US6301609B1 (en) | 1999-07-07 | 2001-10-09 | Lucent Technologies Inc. | Assignable associate priorities for user-definable instant messaging buddy groups |
| US6404746B1 (en) * | 1999-07-13 | 2002-06-11 | Intervoice Limited Partnership | System and method for packet network media redirection |
| US7005985B1 (en) | 1999-07-20 | 2006-02-28 | Axcess, Inc. | Radio frequency identification system and method |
| US6453034B1 (en) | 1999-07-29 | 2002-09-17 | Mci Worldcom, Inc. | Method of and system for extending internet telephony over virtual private network direct access lines |
| US6760324B1 (en) | 1999-09-10 | 2004-07-06 | Array Telecom Corporation | Method, system, and computer program product for providing voice over the internet communication |
| US6681252B1 (en) | 1999-09-27 | 2004-01-20 | 3Com Corporation | System and method for interconnecting portable information devices through a network based telecommunication system |
| US6744759B1 (en) | 1999-09-27 | 2004-06-01 | 3Com Corporation | System and method for providing user-configured telephone service in a data network telephony system |
| US6335968B1 (en) | 1999-09-30 | 2002-01-01 | Bellsouth Intellectual Property Corporation | System and method for pre-paid and pay-per-use internet services |
| US6434143B1 (en) | 1999-11-08 | 2002-08-13 | Mci Worldcom, Inc. | Internet protocol telephony voice/video message deposit and retrieval |
| US6650901B1 (en) | 2000-02-29 | 2003-11-18 | 3Com Corporation | System and method for providing user-configured telephone service in a data network telephony system |
| US6937563B2 (en) | 2001-03-08 | 2005-08-30 | Nortel Networks Limited | Homing and controlling IP telephones |
| US6954654B2 (en) | 2001-07-31 | 2005-10-11 | Lucent Technologies Inc. | Provision of services in a communication system including an interworking mobile switching center |
-
1999
- 1999-11-08 US US09/436,796 patent/US7860114B1/en not_active Expired - Fee Related
-
2000
- 2000-11-08 JP JP2001540473A patent/JP2003515969A/en not_active Withdrawn
- 2000-11-08 CN CN00818189.6A patent/CN1421081A/en active Pending
- 2000-11-08 AU AU43036/01A patent/AU4303601A/en not_active Abandoned
- 2000-11-08 WO PCT/US2000/041994 patent/WO2001039444A1/en not_active Application Discontinuation
- 2000-11-08 BR BR0015413-0A patent/BR0015413A/en not_active IP Right Cessation
- 2000-11-08 EP EP00992326A patent/EP1230770A4/en not_active Withdrawn
- 2000-11-08 MX MXPA02004607A patent/MXPA02004607A/en unknown
- 2000-11-08 CA CA002391037A patent/CA2391037A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| EP1230770A4 (en) | 2004-08-25 |
| MXPA02004607A (en) | 2003-06-24 |
| CN1421081A (en) | 2003-05-28 |
| AU4303601A (en) | 2001-06-04 |
| EP1230770A1 (en) | 2002-08-14 |
| WO2001039444A9 (en) | 2002-08-15 |
| US7860114B1 (en) | 2010-12-28 |
| BR0015413A (en) | 2002-09-17 |
| JP2003515969A (en) | 2003-05-07 |
| WO2001039444A1 (en) | 2001-05-31 |
| WO2001039444A8 (en) | 2001-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8743892B2 (en) | Method and system for dynamic gateway selection in an IP telephony network | |
| US7860114B1 (en) | Method and system for dynamic gateway selection in an IP telephony network | |
| Andreasen et al. | Media gateway control protocol (MGCP) version 1.0 | |
| US8239468B2 (en) | Session QoS control apparatus | |
| US7787501B2 (en) | Congestion control in an IP network | |
| US7050424B2 (en) | Method and system for automatic proxy server workload shifting for load balancing | |
| US8249102B2 (en) | Method and apparatus for session layer framing to enable interoperability between packet-switched systems | |
| US6798745B1 (en) | Quality of service management for voice over packet networks | |
| EP1616420B1 (en) | Method for verification of communication path in ip telephony ping | |
| CA2554416C (en) | Congestion handling in a packet communication system | |
| JP2002314617A (en) | Ip packet access gateway(ip pag) system and method for managing ip bearer path between ip endpoints, and computer program product | |
| US9281996B1 (en) | Method and system for dynamic gateway selection in an IP telephony network | |
| WO2008085333A2 (en) | Dynamic service triggers in communication networks | |
| EP2140670B1 (en) | Implementing an emergency services solution | |
| EP1436963B1 (en) | Method, apparatus and computer program for selecting a media gateway control function based on the monitoring of resources of media gateway functions | |
| EP1962464B1 (en) | Method, communication system and entity for overlap code sending using session initiation protocol | |
| WO2011029085A2 (en) | Methods, systems, and computer readable media for verifying the availability of an internet protocol (ip) media router during a call setup | |
| US20080069089A1 (en) | Method for Transmitting Signalling Information Via a Network Limiting Element in a Communications Network | |
| Cisco | Cisco IOS Voice, Video, and Fax Commands: Si through Z | |
| US7747672B1 (en) | Method and apparatus using lightweight RRQ for efficient recovery of a call signaling channel in gatekeeper-routed call signaling | |
| MXPA06008332A (en) | Congestion handling in a packet communication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |